Like any kind of apps, JavaScript apps also have to be written well.
Otherwise, we run into all kinds of issues later on.
In this article, we’ll look at some best practices we should follow when writing JavaScript code.
Don’t Bundle Everything Together
We shouldn’t bundle everything together into one big package.
HTTP/2 no longer has bi overhead when making multiple HTTP requests.
Therefore, there’s no advantage to bundling everything up.
Browser caching is also hard with this approach since any change will invalidate the cache.
This will force users to download everything again.
That results in lots of wasted bandwidth.
HTTP/2 is supported by 95% of the clients worldwide, so we can assume that we don’t need to bundle everything together.
Best Way to Bundle Items
Separate vendor and client code is the best approach
This solves the issue where a small change will force the user to download everything again.
If our own code changes, then only the client code is changed.
The vendor code remains the same since we didn’t change the library code.
This saves us lots of bandwidth.
With Webpack, this requires extra code-splitting config to tell Webpack where the vendor code lives.
They should live in the node_modules folder.
So in the built index.html file, we get:
<script src="vendor.[hash].min.js"></script>
<script src="index.[hash].min.js"></script>
We can improve this further.
The vendor file can be split into smaller pieces.
For example, we can write:
<script src="vendor.react.[hash].min.js"></script>
<script src="vendor.others.[hash].min.js"></script>
<script src="index.[hash].min.js"></script>
to split the React files from the rest of the library files.
This is because the React libraries change slower than the other ones, so we can keep them cached separately.
Public CDN
We shouldn’t keep all our dependencies in the bundles instead of having some in the CDN.
The code is downloaded once per domain and the cache is sandboxed because of privacy implications.
This is because of the partitioned cache feature that separates the caches for users from different domains.
Also, using CDN means that we need to do all the request stuff for every domain.
DNS resolution, initial connection, and SSL handshake all required to be done.
Hitting the CDN means that we have to do those things for one more domain.
So having everything in the same domain will reduce the overhead.
Vendor versions would also be fragmented since the library versions on different CDNs are different.
If we browse from one site that uses one CDN and another that uses a different one, then they’ve to be downloaded again.
CDNs can also have other issues like malicious code injected into them.
Privacy may also be a concern since some people may harvest data from 3rd party requests.
And CDNs are a single point of failure.
The Best Way
Therefore, the best way is to use packages for all our dependencies and then build them into vendor and index JavaScript files.
Then we can put them behind our own non-shared CDN so that they can be downloaded by users and cached until we deploy the next set of changes.
They can be smaller because of HTTP/2 caching and fast performance when making multiple requests.
Conclusion
We should bundle our files into chunks consisting of one or more with 3rd libraries and another with our own code.
