JavaScript Bundles Are Too Big : Break Up The Libraries
You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
What Is A Library?
To put it blunt, it’s a building with lots of books. Take a book, maybe 2 or 3 , but try to take the entire Philosophy section in a shopping trolley because you need to read just one… Welcome to JavaScript!
But what about Tree Shaking? Correct me If I’m wrong, it eliminates dead code but not unused referenced code (which is sometimes most/ all of some code bases). I’m not clued up on static analysis code elimination tools or if I just completely made that up but I think a partial solution to reducing code on the front end is far more elementary than that, it needs to start with library authors.
Too many JS Libraries Are Clumsy And Old School
They don’t just have features you need, they sometimes have dozens of features you may never touch in your lifetime. So why are they contained in a single bundle?
The Good: RxJS
I’ve barely touched the surface with RxJS, but the one thing I love about it is that it is broken up into its primary constituents.
Want to use Observable?
Oh no, you had to type two extra lines to save over 100KB+, traumatic. Despite your bundler (Browserify, Webpack 1/2, Rollup, Gulp, Grunt, node.js etc) you get just those features and their dependencies.
The Good: D3 version 4
D3 has always been a heavy library, the latest minified totals to 213KB. It is also broken up into dozens of modules to import what you need: npm install d3-shape . You can download each module as part of the library or as a standalone library. Sounds familiar? sounds a little like…
The Good: Lodash Cli
If you’re not familiar with Lodash it’s a popular functional programming library known for its consistency and performance. It has a CLI that allows you to build combined/ individual modules in various module formats (except ES modules).
The Bad: jQuery
jQuery is the most mis-understood front-end lib, it deserves way more respect than what it receives, but it is a culprit of wasting bloat. $ has hundreds of features but most devs rarely use the majority of them in a single project. jQuery Builder was not as popular as it deserved to be but going by its philosophy jQuery broken up would look something like this:
- jquery.ajax.min.js
- jquery.css.min.js
- jquery.depreciated.min.js
- jquery.effects.min.js
- jquery.events.min.js
- jquery.offset.min.js
- jquery.wrap.min.js
- jquery.sizzle.min.js
This is what I mean by break up the libraries (break up the big libs, “too big to fail”).
The Ugly: three.js
One of the largest JavaScript libs out there, it’s huge but totally with good reason. Props to the maintainers as it has been updated to support ES modules in recent months but it’s definitely a library that should be split up.
Conclusion
Notice that some of the most enterprise heavy JavaScript libraries have evolved to be the most considerate to user bandwidth. This is no longer the era of all or nothing. Of course, not every library warrants multiple distribution files but ask yourself
Why am I bundling a big ass library into one file?
What’s considered as big? Nobody knows but I get suspicious of anything over 20KB minified and gzipped. sounds like OCD but 5 of those libs = 100kB, + latency & concurrency of other assets and in reality it could result in seconds being added to a basic smart phone with “average” reception. The maths is no linear.
Reality check… Yes devs do save time importing one big plugin but “AT THE END USER’S EXPENSE”
Prioritise the generation of light-weight footprints and efficiency above other over-saturated and over-obsessed JS concerns (props to the rants of Alex Russell & Jason Miller (Preact)).
It is far better to bundle 100+ distribution files than one big fat 200+KB bundle where probably like 5% of features are probably utilised in real life (don’t quote me on this, just a rant-ish thoughtless estimation). I am also a culprit of not breaking up libs, but I’m certain this is the way forward.
Thanks for the read ;)
