The Unhealthy Obsession with JavaScript Bundle Size

Are we a bit too obsessed with size?

Ryan Carniato
The Startup

--

Woman measuring her tummy from rawpixels.com

Disclaimer: this article doesn’t suggest you shouldn’t be looking at your application bundle size with interest. The median size of JavaScript has been growing year over year to a place we shouldn’t just accept that. We should be aware of the decision to use libraries. More this is focused on the race to the bottom for libraries competing purely on their bundlephobia.com scores. It can be misleading and often smaller isn’t always better.

I wanted to take a moment to talk about what I consider the most overhyped facet of JavaScript performance these days: Bundle Size. What I’m talking about is after all the minification and uglification the size in kilobytes that you end up sending to your end-consumer. We all know that smaller is better. Less to transfer over the wire leads to quicker page loads. A few hundred milliseconds is all it takes to go from fast and smooth to slow and clunky. It’s as much of a perception thing as any. But it’s an important consideration.

So how did this became such a hot topic? For years as JavaScript libraries became more sophisticated and their capabilities grew and more and more work got offloaded to the client that was classically done on the server. Before long what had once started as a few simple libraries had…

--

--

Ryan Carniato
The Startup

FrontEnd JS Performance Enthusiast and Long Time Super Fan of Fine Grained Reactive Programming. Member of Marko Core Team. Author of SolidJS UI Library.