- At the very beginning of this course
I talked about HTTP/2 and multiplexing,
the ability of the browser to pull down
many files at the same time
rather than one file after the other.
This new ability is challenging how we think
about serving JavaScript to the browser.
So bear with me here.
As websites and applications started relying more
and more on JavaScript and front-end frameworks like react.
Developers ran into a significant performance issue
with the old HTTP 1.1 protocol.
Big JavaScript applications
with a lot of different files and components,
created major rendering roadblocks
because the browser would stop rendering
until all the files were downloaded
and all those files came one after the other.
To solve this problem,
developers started bundling all of their JavaScript
into one single file.
With a single file,
there was no issue with waiting for files to load or
for files loading in the wrong order or anything like that.
But, those files got very big, very fast,
which replaced one performance issue with another.
From a technical perspective
these original problems are in the past.
Thanks to HTTP/2 and multiplexing.
In reality, they're still very much present,
because although the technology has moved on,
the tool chain and development practices have not,
but they're starting to.
Here's the thing, this whole idea
of bundling all JavaScript into one big file,
makes no sense on the modern web.
First of all, we now have multiplexing.
Second of all.
The modern web platform supports JavaScript modules,
separate JavaScript files that export
and import objects functions,
and other primitives from each other.
Just a few years ago,
such modules had to be transformed
into larger JavaScript bundles to work
using a tool like bundler.
Today, that's no longer necessary.
That changes everything
about how we think about loading JavaScript.
If we ignore all the frameworks
and build tools and everything else for a second
and just look at the concept of JavaScript loading,
here's what should be happening
from a performance perspective.
On initial load any critical JavaScript necessary
to get the app framework up and running
and displaying something above the fold should be loaded.
Once that's done.
And the user has something to look at,
any necessary JavaScript modules
for functionality should be loaded.
And from here on out, the browsers should progressively
load JavaScript modules only when they become relevant.
Because the user scrolls to where they are,
or click a button or do something else to
trigger an interaction that requires more JavaScript.
In other words,
JavaScript functionality should be modularized as much
as possible and split into dedicated files.
There are several immediate benefits to this approach.
First off,
this is how modern web applications are already built.
React, uses components.
JavaScript modules are the exact same thing.
Except they run on the web platform itself
and you don't need a bundler to make them work.
Number two, modularization makes ongoing development easier
because it provides clear separation of concerns.
Number three, modularizing, JavaScript
and loading modules only when they are needed,
brings significant performance benefits on initial load.
And number four, modularization means updating some feature
in a JavaScript app does not require the browser
to download the entire app bundle again.
It just needs to download the updated module file
with its features, which is way smaller.
The good news is we're starting to see build tools
take advantage of this new feature in the web platform,
and use JavaScript modules for this purpose.
That includes snowpack, parcel, roll up, even webpack.
Existing build tools like webpack,
also support this approach through code splitting.
So does this mean JavaScript bundling
will become a thing of the past?
No, I don't think so.
It does mean the days of serving up one huge app bundle
for all our JavaScript is over though.
Instead we can now more carefully design a loading strategy
for our JavaScript for optimal performance.
And that's done using the breakdown I provided earlier.
First, critical JavaScript,
then necessary functionality, and then lazy load the rest.
I'll talk a lot more about lazy loading JavaScript
a little later on in the course.