The latest Firebase JavaScript SDK (version 9.0) has been rewritten as a functional library resulting far smaller bundle sizes for better web performance. Learn how to upgrade your Firebase web app https://fireship.io/courses/

#firebase #javascript #firstlook

🔗 Resources

Get Started with Firebase https://youtu.be/q5J5ho7YUhA
Firebase Blog https://firebase.googleblog.com/2021/07/introducing-the-new-firebase-js-sdk.html

🔥 Watch more with Fireship PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T14:01:46.477Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
fdb7dbeb-2b35-42d1-a7b8-3f190f6ec9f7
ef5d2848b12a797c0651b687070a450cbe669b972bc74dbd268a0028fd418bce
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Firebase is on the decline, and by that, I mean its JavaScript bundle size.
One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done.
A large bundle size can lead to poor performance and a bad user experience.
But I have some good news.
Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application.
In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes.
But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses.
System.
As developers, we always wanna use the latest and greatest technology.
Gentlemen, we can rebuild him.
We have the technology.
But at the same time, we hate dealing with breaking changes.
The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code.
The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports.
You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on.
This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application.
For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network.
Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle.
In other words, it's a tree shakeable library.
Now another cool thing in the new SDK is that there's a Firestore lite package.
Firestore is the biggest module in Firebase.
But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package.
That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like.
I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag.
That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video.
The only important thing is that version 9 is installed.
Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0.
So the first thing I'll do is import Firebase the old way.
The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code.
As you can see here, I'm performing a side effect import for auth, Firestore, and storage.
This should look familiar minus the compat part if you've ever used Firebase before.
If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it.
That's kind of demoralizing if you care about performance.
Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK.
Instead of a side effect import, We import the functionality that we actually need from each individual module.
Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file.
Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules.
Then after initializing the app, we need to call that function to work with the actual module itself.
This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application.
If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context.
In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with.
Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes.
That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app.
Now, let's go ahead and put one of these functions since to use like sign in with pop up.
Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument.
One thing I don't really love here is that for every function, we need to pass auth as the first argument.
It's not really any more code than dot notation, but it just feels kind of awkward in my opinion.
I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether.
Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments.
If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach.
That's not very to code, but it will require a lot of tedious code changes.
Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time.
And most importantly, it puts an end to the criticism that Firebase is just too big.
I'm gonna go ahead and wrap things up there.

Speaker 0: Firebase is on the decline, and by that, I mean its JavaScript bundle size. One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done. A large bundle size can lead to poor performance and a bad user experience. But I have some good news. Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application.

In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes. But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses. System. As developers, we always wanna use the latest and greatest technology. Gentlemen, we can rebuild him.

We have the technology. But at the same time, we hate dealing with breaking changes. The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code. The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports. You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on.

This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application. For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network. Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle. In other words, it's a tree shakeable library. Now another cool thing in the new SDK is that there's a Firestore lite package.

Firestore is the biggest module in Firebase. But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package. That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like. I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag. That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video.

The only important thing is that version 9 is installed. Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0. So the first thing I'll do is import Firebase the old way. The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code. As you can see here, I'm performing a side effect import for auth, Firestore, and storage.

This should look familiar minus the compat part if you've ever used Firebase before. If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it. That's kind of demoralizing if you care about performance. Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK. Instead of a side effect import, We import the functionality that we actually need from each individual module.

Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file. Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules. Then after initializing the app, we need to call that function to work with the actual module itself. This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application. If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context.

In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with. Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes. That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app. Now, let's go ahead and put one of these functions since to use like sign in with pop up. Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument.

One thing I don't really love here is that for every function, we need to pass auth as the first argument. It's not really any more code than dot notation, but it just feels kind of awkward in my opinion. I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether. Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments. If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach.

That's not very to code, but it will require a lot of tedious code changes. Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time. And most importantly, it puts an end to the criticism that Firebase is just too big. I'm gonna go ahead and wrap things up there.
Firebase is on the decline, and by that, I mean its JavaScript bundle size. One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done. A large bundle size can lead to poor performance and a bad user experience. But I have some good news. Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application. In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes. But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses.
System. As developers, we always wanna use the latest and greatest technology. Gentlemen, we can rebuild him. We have the technology. But at the same time, we hate dealing with breaking changes. The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code.
technology
The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports. You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on. This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application. For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network. Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle.
In other words, it's a tree shakeable library. Now another cool thing in the new SDK is that there's a Firestore lite package. Firestore is the biggest module in Firebase. But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package. That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like.
databases
streaming
I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag. That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video. The only important thing is that version 9 is installed. Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0. So the first thing I'll do is import Firebase the old way. The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code. As you can see here, I'm performing a side effect import for auth, Firestore, and storage. This should look familiar minus the compat part if you've ever used Firebase before. If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it. That's kind of demoralizing if you care about performance. Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK. Instead of a side effect import, We import the functionality that we actually need from each individual module. Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file. Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules. Then after initializing the app, we need to call that function to work with the actual module itself. This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application. If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context. In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with. Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes. That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app. Now, let's go ahead and put one of these functions since to use like sign in with pop up. Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument. One thing I don't really love here is that for every function, we need to pass auth as the first argument. It's not really any more code than dot notation, but it just feels kind of awkward in my opinion.
I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether. Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments.
ideologies
If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach. That's not very to code, but it will require a lot of tedious code changes. Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time. And most importantly, it puts an end to the criticism that Firebase is just too big. I'm gonna go ahead and wrap things up there.
Firebase is on the decline, and by that, I mean its JavaScript bundle size. One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done. A large bundle size can lead to poor performance and a bad user experience. But I have some good news. Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application. In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes. But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses. System. As developers, we always wanna use the latest and greatest technology. Gentlemen, we can rebuild him. We have the technology. But at the same time, we hate dealing with breaking changes. The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code. The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports. You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on. This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application. For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network. Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle. In other words, it's a tree shakeable library. Now another cool thing in the new SDK is that there's a Firestore lite package. Firestore is the biggest module in Firebase. But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package. That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like. I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag. That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video. The only important thing is that version 9 is installed. Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0. So the first thing I'll do is import Firebase the old way. The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code. As you can see here, I'm performing a side effect import for auth, Firestore, and storage. This should look familiar minus the compat part if you've ever used Firebase before. If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it. That's kind of demoralizing if you care about performance. Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK. Instead of a side effect import, We import the functionality that we actually need from each individual module. Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file. Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules. Then after initializing the app, we need to call that function to work with the actual module itself. This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application. If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context. In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with. Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes. That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app. Now, let's go ahead and put one of these functions since to use like sign in with pop up. Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument. One thing I don't really love here is that for every function, we need to pass auth as the first argument. It's not really any more code than dot notation, but it just feels kind of awkward in my opinion. I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether. Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments. If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach. That's not very to code, but it will require a lot of tedious code changes. Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time. And most importantly, it puts an end to the criticism that Firebase is just too big. I'm gonna go ahead and wrap things up there.
Firebase
firebase
is
is
on
on
the
the
decline,
decline
and
and
by
by
that,
that
I
i
mean
mean
its
its
JavaScript
javascript
bundle
bundle
size.
size
One
one
of
of
the
the
biggest
biggest
criticisms
criticisms
developers
developers
have
have
about
about
Firebase
firebase
is
is
that
that
it
it
requires
requires
a
a
lot
lot
of
of
kilobytes
kilobytes
of
of
JavaScript
javascript
script
script
to
to
get
get
the
the
job
job
done.
done
A
a
large
large
bundle
bundle
size
size
can
can
lead
lead
to
to
poor
poor
performance
performance
and
and
a
a
bad
bad
user
user
experience.
experience
But
but
I
i
have
have
some
some
good
good
news.
news
Firebase
firebase
is
is
releasing
releasing
a
a
brand
brand
new
new
JavaScript
javascript
SDK
sdk
that
that
can
can
dramatically
dramatically
reduce
reduce
the
the
size
size
of
of
your
your
web
web
application.
application
In
in
today's
today's
video,
video
you'll
you'll
learn
learn
how
how
to
to
upgrade
upgrade
your
your
existing
existing
Firebase
firebase
app
app
to
to
reduce
reduce
the
the
bundle
bundle
size
size
by
by
more
more
than
than
50,
50
sent,
sent
and
and
I'll
i'll
also
also
give
give
you
you
my
my
first
first
impressions
impressions
about
about
what
what
I
i
like
like
and
and
dislike
dislike
about
about
this
this
new
new
SDK
sdk
because
because
it's
it's
filled
filled
with
with
breaking
breaking
changes.
changes
But
but
first,
first
If
if
you're
you're
serious
serious
about
about
building
building
a
a
Firebase
firebase
app,
app
consider
consider
upgrading
upgrading
to
to
Pro
pro
on
on
Fireship
fireship
IO
io
to
to
get
get
access
access
to
to
my
my
full
full
project
project
based
based
courses.
courses
System.
system
As
as
developers,
developers
we
we
always
always
wanna
wanna
use
use
the
the
latest
latest
and
and
greatest
greatest
technology.
technology
Gentlemen,
gentlemen
we
we
can
can
rebuild
rebuild
him.
him
We
we
have
have
the
the
technology.
technology
But
but
at
at
the
the
same
same
time,
time
we
we
hate
hate
dealing
dealing
with
with
breaking
breaking
changes.
changes
The
the
new
new
Firebase
firebase
SDK
sdk
makes
makes
it
it
possible
possible
to
to
build
build
apps
apps
with
with
a
a
much
much
smaller
smaller
JavaScript
javascript
footprint,
footprint
but
but
it
it
comes
comes
at
at
the
the
cost
cost
of
of
a
a
lot
lot
of
of
breaking
breaking
changes
changes
that
that
you'll
you'll
have
have
to
to
refactor
refactor
in
in
your
your
code.
code
The
the
problem
problem
is
is
that
that
Firebase
firebase
has
has
been
been
around
around
for
for
a
a
long
long
time,
time
and
and
it
it
uses
uses
what
what
are
are
known
known
as
as
side
side
effect
effect
imports.
imports
You
you
import
import
and
and
initialize
initialize
your
your
Firebase
firebase
app,
app
which
which
creates
creates
a
a
global
global
Firebase
firebase
object,
object
then
then
and
and
extend
extend
it
it
with
with
additional
additional
functionality
functionality
by
by
importing
importing
other
other
modules
modules
like
like
auth,
auth
Firestore,
firestore
storage,
storage
and
and
so
so
on.
on
This
this
creates
creates
a
a
lot
lot
of
of
bloat
bloat
code
code
because
because
these
these
imports
imports
add
add
a
a
bunch
bunch
of
of
functionality
functionality
that
that
you're
you're
probably
probably
not
not
going
going
to
to
use
use
in
in
your
your
application.
application
For
for
example,
example
your
your
app
app
might
might
use
use
email
email
password
password
login,
login
but
but
importing
importing
the
the
auth
auth
module
module
adds
adds
the
the
code
code
for
for
every
every
other
other
sign
sign
in
in
method
method
on
on
the
the
platform,
platform
which
which
is
is
nothing
nothing
but
but
dead
dead
code
code
that
that
your
your
end
end
user
user
has
has
to
to
download
download
from
from
the
the
network.
network
Instead
instead
of
of
accessing
accessing
methods
methods
on
on
one
one
giant
giant
object
object
with
with
dot
dot
notation,
notation
the
the
new
new
SDK
sdk
takes
takes
a
a
functional
functional
approach,
approach
allowing
allowing
you
you
to
to
import
import
the
the
exact
exact
functionality
functionality
that
that
you
you
need,
need
and
and
that
that
means
means
everything
everything
else
else
can
can
be
be
excluded
excluded
from
from
the
the
JavaScript
javascript
bundle.
bundle
In
in
other
other
words,
words
it's
it's
a
a
tree
tree
shakeable
shakeable
library.
library
Now
now
another
another
cool
cool
thing
thing
in
in
the
the
new
new
SDK
sdk
is
is
that
that
there's
there's
a
a
Firestore
firestore
lite
lite
package.
package
Firestore
firestore
is
is
the
the
biggest
biggest
module
module
in
in
Firebase.
firebase
But
but
if
if
you
you
wanna
wanna
use
use
the
the
database
database
and
and
don't
don't
need
need
things
things
like
like
real
real
time
time
listeners
listeners
or
or
offline
offline
mode,
mode
you
you
can
can
use
use
the
the
Lite
lite
package,
package
which
which
is
is
84%
84%
smaller
smaller
than
than
the
the
normal
normal
package.
package
That's
that's
pretty
pretty
awesome,
awesome
but
but
now
now
let's
let's
jump
jump
into
into
the
the
code
code
and
and
see
see
what
what
these
these
breaking
breaking
changes
changes
actually
actually
look
look
like.
like
I'm
i'm
using
using
Vite
vite
as
as
my
my
build
build
SQL,
sql
and
and
the
the
first
first
thing
thing
I'll
i'll
do
do
is
is
install
install
the
the
Firebase
firebase
SDK
sdk
using
using
the
the
beta
beta
tag.
tag
That'll
that'll
install
install
version
version
9
9
of
of
the
the
SDK,
sdk
but
but
the
the
beta
beta
tag
tag
may
may
not
not
be
be
required
required
depending
depending
on
on
when
when
you're
you're
watching
watching
this
this
video.
video
The
the
only
only
important
important
thing
thing
is
is
that
that
version
version
9
9
is
is
installed.
installed
Now,
now
if
if
I
i
go
go
into
into
the
the
JavaScript
javascript
file,
file
it's
it's
currently
currently
empty,
empty
giving
giving
us
us
a
a
bundle
bundle
size
size
of
of
0.
0
So
so
the
the
first
first
thing
thing
I'll
i'll
do
do
is
is
import
import
Firebase
firebase
the
the
old
old
way.
way
The
the
nice
nice
thing
thing
about
about
this
this
SDK
sdk
is
is
that
that
it
it
gives
gives
you
you
a
a
compact
compact
library,
library
allowing
allowing
you
you
to
to
upgrade
upgrade
your
your
code
code
base
base
with
with
minimal
minimal
modifications
modifications
to
to
for
for
existing
existing
code.
code
As
as
you
you
can
can
see
see
here,
here
I'm
i'm
performing
performing
a
a
side
side
effect
effect
import
import
for
for
auth,
auth
Firestore,
firestore
and
and
storage.
storage
This
this
should
should
look
look
familiar
familiar
minus
minus
the
the
compat
compat
part
part
if
if
you've
you've
ever
ever
used
used
Firebase
firebase
before.
before
If
if
we
we
go
go
ahead
ahead
and
and
build
build
the
the
app,
app
you
you
can
can
see
see
that
that
our
our
bundle
bundle
size
size
is
is
now
now
630
630
kilobytes,
kilobytes
which
which
triggers
triggers
a
a
warning,
warning
and,
and
broadly,
broadly
that
that
compressor
compressor
won't
won't
even
even
touch
touch
it.
it
That's
that's
kind
kind
of
of
demoralizing
demoralizing
if
if
you
you
care
care
about
about
performance.
performance
Let's
let's
go
go
ahead
ahead
and
and
remove
remove
this
this
code
code
and
and
look
look
at
at
how
how
tree
tree
shakeable
shakeable
imports
imports
work
work
in
in
the
the
new
new
SDK.
sdk
Instead
instead
of
of
a
a
side
side
effect
effect
import,
import
We
we
import
import
the
the
functionality
functionality
that
that
we
we
actually
actually
need
need
from
from
each
each
individual
individual
module.
module
Like,
like
if
if
we
we
want
want
to
to
sign
sign
up
up
a
a
user
user
with
with
Google,
google
we
we
can
can
bring
bring
in
in
sign
sign
in
in
with
with
pop
pop
up
up
and
and
sign
sign
out
out
from
from
the
the
auth
auth
module,
module
or
or
upload
upload
bytes
bytes
from
from
storage
storage
to
to
upload
upload
a
a
file.
file
Now
now
one
one
thing
thing
that's
that's
kind
kind
of
of
weird
weird
is
is
that
that
you'll
you'll
notice
notice
we
we
import
import
a
a
function
function
called
called
get
get
auth,
auth
get
get
storage,
storage
and
and
get
get
Firestore
firestore
for
for
each
each
one
one
of
of
these
these
modules.
modules
Then
then
after
after
initializing
initializing
the
the
app,
app
we
we
need
need
to
to
call
call
that
that
function
function
to
to
work
work
with
with
the
the
actual
actual
module
module
itself.
itself
This
this
is
is
like
like
an
an
initialization
initialization
step
step
that
that
is
is
required
required
because
because
it's
it's
possible
possible
to
to
have
have
multiple
multiple
Firebase
firebase
projects
projects
used
used
in
in
a
a
single
single
front
front
end
end
application.
application
If
if
you
you
are
are
using
using
multiple
multiple
Firebase
firebase
projects,
projects
You
you
can
can
pass
pass
the
the
Firebase
firebase
app
app
as
as
an
an
argument
argument
to
to
give
give
that
that
module
module
the
the
proper
proper
context.
context
In
in
the
the
old
old
SDK,
sdk
you
you
would
would
have
have
used
used
dot
dot
notation
notation
on
on
the
the
Firebase
firebase
app
app
to
to
access
access
the
the
feature
feature
that
that
you're
you're
working
working
with.
with
Now,
now
if
if
we
we
go
go
ahead
ahead
and
and
build
build
the
the
app
app
at
at
this
this
point,
point
you
you
can
can
see
see
our
our
bundle
bundle
size
size
has
has
been
been
reduced
reduced
all
all
the
the
way
way
down
down
to
to
206
206
kilobytes.
kilobytes
That's
that's
a
a
third
third
of
of
the
the
size
size
it
it
was
was
previously,
previously
or
or
42
42
kilobytes
kilobytes
compressed,
compressed
which
which
is
is
a
a
much
much
more
more
reasonable
reasonable
starting
starting
point
point
considering
considering
we
we
have
have
all
all
kinds
kinds
of
of
functionality
functionality
ready
ready
to
to
go
go
in
in
this
this
app.
app
Now,
now
let's
let's
go
go
ahead
ahead
and
and
put
put
one
one
of
of
these
these
functions
functions
since
since
to
to
use
use
like
like
sign
sign
in
in
with
with
pop
pop
up.
up
Now
now
in
in
order
order
to
to
use
use
it,
it
we
we
pass
pass
the
the
auth
auth
object
object
as
as
the
the
first
first
argument,
argument
then
then
the
the
provider,
provider
which
which
might
might
be
be
something
something
like
like
Facebook
facebook
or
or
GitHub
github
as
as
the
the
second
second
argument.
argument
One
one
thing
thing
I
i
don't
don't
really
really
love
love
here
here
is
is
that
that
for
for
every
every
function,
function
we
we
need
need
to
to
pass
pass
auth
auth
as
as
the
the
first
first
argument.
argument
It's
it's
not
not
really
really
any
any
more
more
code
code
than
than
dot
dot
notation,
notation
but
but
it
it
just
just
feels
feels
kind
kind
of
of
awkward
awkward
in
in
my
my
opinion.
opinion
I
i
find
find
myself
myself
wanting
wanting
to
to
create
create
my
my
own
own
custom
custom
abstraction,
abstraction
like
like
a
a
class,
class
or
or
maybe
maybe
just
just
a
a
helper
helper
function
function
to
to
get
get
rid
rid
of
of
that
that
auth
auth
object
object
altogether.
altogether
Maybe
maybe
that's
that's
just
just
me,
me
but
but
I'm
i'm
curious
curious
what
what
you
you
guys
guys
think
think
about
about
the
the
ergonomics
ergonomics
of
of
this
this
SDK,
sdk
so
so
let
let
me
me
know
know
in
in
the
the
comments.
comments
If
if
you
you
have
have
an
an
existing
existing
project,
project
Your
your
breaking
breaking
changes
changes
can
can
be
be
overcome
overcome
by
by
simply
simply
refactoring
refactoring
your
your
dot
dot
notation
notation
to
to
this
this
more
more
functional
functional
approach.
approach
That's
that's
not
not
very
very
to
to
code,
code
but
but
it
it
will
will
require
require
a
a
lot
lot
of
of
tedious
tedious
code
code
changes.
changes
Overall,
overall
I
i
think
think
this
this
new
new
SDK
sdk
is
is
a
a
great
great
direction
direction
for
for
Firebase,
firebase
and
and
will
will
allow
allow
them
them
to
to
add
add
new
new
functionality
functionality
to
to
the
the
SDK
sdk
without
without
increasing
increasing
your
your
functionality
functionality
to
to
the
the
SDK
sdk
without
without
increasing
increasing
your
your
bundle
bundle
size
size
every
every
time.
time
And
and
most
most
importantly,
importantly
it
it
puts
puts
an
an
end
end
to
to
the
the
criticism
criticism
that
that
Firebase
firebase
is
is
just
just
too
too
big.
big
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
success
The speaker discusses the benefits of using the new JavaScript SDK for building apps, including reducing the bundle size and avoiding breaking changes. They also explain the use of side effect imports and the use of Fir analysis for each module. The speaker concludes that the new SDK is a great direction for developers to use and will allow them to add new functionality to the SDK without increasing their functionality to the bundle size.
The Decline of Firebase (bundle sizes) // New JavaScript SDK First Look
Firebase is on the decline, and by that, I mean its JavaScript bundle size. One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done. A large bundle size can lead to poor performance and a bad user experience. But I have some good news. Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application. In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes. But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses. System. As developers, we always wanna use the latest and greatest technology. Gentlemen, we can rebuild him. We have the technology. But at the same time, we hate dealing with breaking changes. The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code. The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports. You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on. This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application. For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network. Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle. In other words, it's a tree shakeable library. Now another cool thing in the new SDK is that there's a Firestore lite package. Firestore is the biggest module in Firebase. But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package. That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like. I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag. That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video. The only important thing is that version 9 is installed. Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0. So the first thing I'll do is import Firebase the old way. The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code. As you can see here, I'm performing a side effect import for auth, Firestore, and storage. This should look familiar minus the compat part if you've ever used Firebase before. If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it. That's kind of demoralizing if you care about performance. Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK. Instead of a side effect import, We import the functionality that we actually need from each individual module. Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file. Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules. Then after initializing the app, we need to call that function to work with the actual module itself. This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application. If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context. In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with. Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes. That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app. Now, let's go ahead and put one of these functions since to use like sign in with pop up. Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument. One thing I don't really love here is that for every function, we need to pass auth as the first argument. It's not really any more code than dot notation, but it just feels kind of awkward in my opinion. I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether. Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments. If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach. That's not very to code, but it will require a lot of tedious code changes. Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time. And most importantly, it puts an end to the criticism that Firebase is just too big. I'm gonna go ahead and wrap things up there.
The speaker discusses the benefits of using the new JavaScript SDK for building apps, including reducing the bundle size and avoiding breaking changes. They also explain the use of side effect imports and the use of Fir analysis for each module. The speaker concludes that the new SDK is a great direction for developers to use and will allow them to add new functionality to the SDK without increasing their functionality to the bundle size.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : The Decline of Firebase (bundle sizes) // New JavaScript SDK First Look 
        and a small summary : The speaker discusses the benefits of using the new JavaScript SDK for building apps, including reducing the bundle size and avoiding breaking changes. They also explain the use of side effect imports and the use of Fir analysis for each module. The speaker concludes that the new SDK is a great direction for developers to use and will allow them to add new functionality to the SDK without increasing their functionality to the bundle size.
        [/INST]
        
        Generate the video : Firebase is on the decline, and by that, I mean its JavaScript bundle size. One of the biggest criticisms developers have about Firebase is that it requires a lot of kilobytes of JavaScript script to get the job done. A large bundle size can lead to poor performance and a bad user experience. But I have some good news. Firebase is releasing a brand new JavaScript SDK that can dramatically reduce the size of your web application. In today's video, you'll learn how to upgrade your existing Firebase app to reduce the bundle size by more than 50, sent, and I'll also give you my first impressions about what I like and dislike about this new SDK because it's filled with breaking changes. But first, If you're serious about building a Firebase app, consider upgrading to Pro on Fireship IO to get access to my full project based courses. System. As developers, we always wanna use the latest and greatest technology. Gentlemen, we can rebuild him. We have the technology. But at the same time, we hate dealing with breaking changes. The new Firebase SDK makes it possible to build apps with a much smaller JavaScript footprint, but it comes at the cost of a lot of breaking changes that you'll have to refactor in your code. The problem is that Firebase has been around for a long time, and it uses what are known as side effect imports. You import and initialize your Firebase app, which creates a global Firebase object, then and extend it with additional functionality by importing other modules like auth, Firestore, storage, and so on. This creates a lot of bloat code because these imports add a bunch of functionality that you're probably not going to use in your application. For example, your app might use email password login, but importing the auth module adds the code for every other sign in method on the platform, which is nothing but dead code that your end user has to download from the network. Instead of accessing methods on one giant object with dot notation, the new SDK takes a functional approach, allowing you to import the exact functionality that you need, and that means everything else can be excluded from the JavaScript bundle. In other words, it's a tree shakeable library. Now another cool thing in the new SDK is that there's a Firestore lite package. Firestore is the biggest module in Firebase. But if you wanna use the database and don't need things like real time listeners or offline mode, you can use the Lite package, which is 84% smaller than the normal package. That's pretty awesome, but now let's jump into the code and see what these breaking changes actually look like. I'm using Vite as my build SQL, and the first thing I'll do is install the Firebase SDK using the beta tag. That'll install version 9 of the SDK, but the beta tag may not be required depending on when you're watching this video. The only important thing is that version 9 is installed. Now, if I go into the JavaScript file, it's currently empty, giving us a bundle size of 0. So the first thing I'll do is import Firebase the old way. The nice thing about this SDK is that it gives you a compact library, allowing you to upgrade your code base with minimal modifications to for existing code. As you can see here, I'm performing a side effect import for auth, Firestore, and storage. This should look familiar minus the compat part if you've ever used Firebase before. If we go ahead and build the app, you can see that our bundle size is now 630 kilobytes, which triggers a warning, and, broadly, that compressor won't even touch it. That's kind of demoralizing if you care about performance. Let's go ahead and remove this code and look at how tree shakeable imports work in the new SDK. Instead of a side effect import, We import the functionality that we actually need from each individual module. Like, if we want to sign up a user with Google, we can bring in sign in with pop up and sign out from the auth module, or upload bytes from storage to upload a file. Now one thing that's kind of weird is that you'll notice we import a function called get auth, get storage, and get Firestore for each one of these modules. Then after initializing the app, we need to call that function to work with the actual module itself. This is like an initialization step that is required because it's possible to have multiple Firebase projects used in a single front end application. If you are using multiple Firebase projects, You can pass the Firebase app as an argument to give that module the proper context. In the old SDK, you would have used dot notation on the Firebase app to access the feature that you're working with. Now, if we go ahead and build the app at this point, you can see our bundle size has been reduced all the way down to 206 kilobytes. That's a third of the size it was previously, or 42 kilobytes compressed, which is a much more reasonable starting point considering we have all kinds of functionality ready to go in this app. Now, let's go ahead and put one of these functions since to use like sign in with pop up. Now in order to use it, we pass the auth object as the first argument, then the provider, which might be something like Facebook or GitHub as the second argument. One thing I don't really love here is that for every function, we need to pass auth as the first argument. It's not really any more code than dot notation, but it just feels kind of awkward in my opinion. I find myself wanting to create my own custom abstraction, like a class, or maybe just a helper function to get rid of that auth object altogether. Maybe that's just me, but I'm curious what you guys think about the ergonomics of this SDK, so let me know in the comments. If you have an existing project, Your breaking changes can be overcome by simply refactoring your dot notation to this more functional approach. That's not very to code, but it will require a lot of tedious code changes. Overall, I think this new SDK is a great direction for Firebase, and will allow them to add new functionality to the SDK without increasing your functionality to the SDK without increasing your bundle size every time. And most importantly, it puts an end to the criticism that Firebase is just too big. I'm gonna go ahead and wrap things up there.
        