There are exciting changes coming to the Firebase JavaScript SDK.
And in this new version, it can greatly reduce
the amount of Firebase code included in your web apps.
If there’s less code in your apps, then that means the pages can be smaller.
And if the pages are smaller, then hopefully that means
that your page is going to load faster.
My name is David East.
I've been working on the Firebase team for over seven years now.
And today I'm going to show you all about what's new in the JS SDK.
We're going to start by learning a bit of a lesson about JavaScript Modules,
because that's everything that this change is based on.
And then after that, we’re going to take a look at the current Firebase JavaScript SDK,
and we're going to use those learnings from that lesson
to see all about the new modular version of the Firebase JavaScript SDK.
And then, lastly, we’re going to take a look at how we can upgrade
from the current version to the upcoming beta version.
So, I want to get started by looking at JavaScript modules
and see why we made this change.
For the longest time,
the standard way of including library code in your site was with the window.
So let’s pretend that I’m using a kitchen library,
you know, like a real kitchen, like something you would make food in.
And including it in your site is fairly simple.
You include a script tag on the page for the library,
and this will attach it to the window.
So below you can create a script tag
and then just reference its namespace on the window.
While this process is straightforward, it does have some limitations.
The identifier for the library, window.kitchen, is called a namespace.
This namespace holds all the methods offered by the library.
Every part of this library is attached to the namespace.
I’m going to use this kitchen to make a smoothie.
It’s pretty easy to access everything this kitchen has, like a blender or a fridge.
The fridge and blender objects even have their own methods attached to them.
The drawback of this window-base library
is that the kitchen namespace has a lot more methods attached to it,
like a microwave, or an oven, dishwasher, stove, toaster.
This code is included in the library, whether you need it or not.
There's many ways to fix this problem,
but the modern way to do so is with JavaScript modules.
JavaScript modules allow you to use syntax
to export code out of a file known as a module.
The kitchen library exports a default function
that acts as the kitchen's namespace.
It returns a kitchen class instance which holds all of the library's methods.
This export allows other modules to import this code,
and you can see in this import file that most of the code here is the same.
And this is actually a problem, because we’re still dealing with a namespace
that includes all of the features of the library.
Modern JavaScript-built tools like webpack, Rollup, and esbuild,
are able to look at these imports and see what’s not being used,
and remove them from your final JavaScript code.
And this is known as tree shaking, and there’s a catch.
For your code to be tree-shakable, you have to write it in a specific way.
Taking a look at the kitchen module, everything is attached to the kitchen class.
Currently, JavaScript-built tools
don’t know how to only remove the needed parts of classes.
To get the import-only-what-you-need approach,
the kitchen library will have to restructure how it exports its code.
Instead of a namespace, it will export individual functions.
Notice that the blender and fridge functions aren't attached to any namespace.
These functions now take in a kitchen as a parameter.
This means that they are no longer a method in a kitchen class.
Even the find and blend functions are not attached to the fridge or blender.
Now, when we write our smoothie code, it's all based on independent functions.
Instead of using a chaining technique,
we pass the results of one function to another.
And if you still want the smoothie code to be two lines,
we can just call the function in the first parameter.
Anything that's not imported
won’t be included in the final JavaScript code.
By following this modular structure,
the kitchen library can add as many features or functions that it wants,
without effecting developers who don’t use them.
With this in mind, let’s take a look at the current Firebase JS SDK.
Every piece of Firebase code I refer to in this video
is backed by an NPM and module bundler workflow.
That means I install Firebase via NPM.
Then, to have all of my library code and application code combined,
I use a module bundler like esbuild.
If you want to learn more about these tools,
check the links in the description on JavaScript build tools.
The current version of the Firebase JavaScript library
follows the namespace approach.
To limit which Firebase services are included in your site,
we use a specific kind of import.
This type of import is called a side effect import.
In this case, the side effect is that importing from firebase/auth
will augment the Firebase namespace by adding firebase/auth.
The same goes for each Firebase service for the web.
While this allows you to include only the services you need,
it isn't always clear what is available on the Firebase namespace.
This is especially true for TypeScript users,
who see all the possible Firebase services available
on the Firebase app typings,
which are not aware of what has been imported.
This side effect approach also doesn’t limit what from that service is included.
You still get all the code for that entire sublibrary.
In this case, when you build this code,
you'll end up with 131 kilobytes, which can be pretty heavy.
And this is where the new library really comes in.
So, get ready, because here is your first look
at the new Firebase JavaScript SDK.
To try out the new Firebase JS SDK,
you need to install it from NPM using the exp tag.
The new Firebase JS SDK is moving away from a namespace,
and towards individual functions,
just like how I shared with you with the kitchen library.
This doesn’t look too different than from before,
but once you start using other Firebase services, you’ll see the change.
Each one of these imports is independent of a namespace.
Then features within each service are also only included if you use them.
Let’s compare this to the namespace version.
It looks really similar, and it's the same amount of lines of code.
But, the big difference is in their size.
The current namespace version comes in at nearly 59 kilobytes,
and the new modular version is at 30 kilobytes.
That's nearly 50% lighter.
It doesn't stop there either.
We’ve added a new library for Firestore users,
Firestore Lite.
Firestore Lite is for those situations
where you don't need real-time streams, or offline persistence.
Firestore Lite shares a similar API with the new modular Firestore library,
with the exception of not being able to stream data in real-time,
or set up offline persistence.
But compare this to the current version of Firestore,
and you'll find that it's a lot smaller.
How much lighter?
Nearly 80% lighter.
Now, I have to keep this video short,
so I can’t show each and every Firebase service
and what its new modular structure looks like.
What I do want to do is show you how you can upgrade to this new modular version.
But keep in mind that everything is in beta still,
so there is subject for some things to change.
But I think that you'll find that upgrading your code base
to this new version might be easier than you’d think,
especially with the compatibility library.
If your site uses a lot of Firebase services,
and you’ve written a lot of Firebase-related code,
you might want an easy way of moving on to this new version.
That’s why we created the compat library.
Take a look at this sample that uses the current Firebase version.
You can upgrade to the newest version by only changing the import path.
This uses the new modular SDK under the hood,
while following the version 8 API.
You don't get the benefit of tree shaking,
but it makes it a lot easier to get started with the upgrade.
Now, let's say you're eager to upgrade to the new Firestore Lite library,
because you don't need real-time or offline persistence.
You can use the compat library
to upgrade only one Firebase service at a time.
You can even use this compatibility library and modular library together while upgrading.
We refer to this as interop mode.
This is a good strategy for upgrading
large code bases to avoid extra large pull requests.
And the great part about the compatibility library
is once you have upgraded your code base, you can remove it entirely.
And that's a 70% decrease in size, while including all of the same features.
The beta version of the Firebase JavaScript SDK is available today.
You can install it via NPM using the exp tag.
And to learn more about the JavaScript SDK, because I only covered a couple of packages,
check out our official documentation,
or just click the links below in the description,
and you can see snippets that are
side by side of the current version with the new version.
And if you want to upgrade your app to the beta version,
then check out the upgrade guide, which lists different methodologies
of upgrading current versions to the new beta version.
And I hope you are as excited about this change as I am.
And if you are upgrading to the beta version,
and you’re seeing performance gains and size reductions,
then let us know, because we’d really, really love to see that.
And I hope that you have a great rest of your Google I/O.