Lately I start to suspect that some JavaScript framework authors may have watched too much late night infomercials. Here are a few popular JavaScript frameworks’ slogans:

• “Super lightweight <1KB JavaScript module system for rapid prototyping"
• “Lightning-fast 1kb JavaScript engine to build front-end applications”
• “Tiny (2 KB) turboboosted JavaScript library for creating user interfaces”

Would you like to count the buzzwords in them? And what does “turboboosted” even mean?

The rise of file size obsession

Buzzwords aside, you can tell these frameworks have a primary focus in their slogans: file size.

In recent years I noticed this trend among many small to medium sized open source projects: the library’s file size is the number one selling point. This is especially prominent in JavaScript community.

The phenomenon is understandable, as JavaScript developers primarily work on the web, where the script’s file size is directly related to the web application’s performance.

This is not to dismiss the importance of web performance. But a good engineer should take all things into context. Caring about performance is normal. What’s taken too far, is this absolute obsession with file size, as though that’s the number one thing that everyone is after.

It is not.

File size is an outdated problem

File size used to matter in the web performance realm back in the good ole web 1.0 days. However, I would argue that slimmer libraries don’t really offer significant advantage anymore with the modern front end workflow.

This is due to the following factors:

Built-in file size reduction measures

A modern front end build process already have many file size reducing options available, such as bundling, minification and gzipping.

These tools greatly reduce the difference among libraries’ file sizes in production environment, rendering the extra effort spent reducing file size on the library side unproductive.

Dead code elimination

Modern front end tooling, like Rollup and Webpack, can even enable tree shaking, or dead code elimination, to make JavaScript modules smaller at build time.

So if you are working on a JavaScript library, perhaps consider letting your customers intelligently reduce its file size as they see fit. Lodash is a great library adopted this mentality.

The heavy-hitters’ elsewhere

In a modern web application, there are simply bigger, better places you can optimize than spending extra time on making a JavaScript library slimmer. The real factors contributing to loading speed are usually static assets like images and media, third party advertisements and tracking scripts, and suboptimal business logic based on data query loops.

Consider this: React (133KB) is powering the mobile web version Facebook, one of the core product on their massive platform. Facebook knows what they are doing. If they are not bothered by React’s file size, then so shouldn’t you.

Direct your energy optimizing the other heavy-hitters. Saving a few kilobytes at what matters the least is penny-wise, pound-foolish.

Focus on clarity: the case of React

What should a JavaScript library really advocate, instead of how tiny the file size, is how this project could make our lives easier. This means it’s important to explain what are the unique advantages and how this project works. Treat a JavaScript library as a start-up product: you don’t see a start-up chanting its elevator pitch by bragging about its tiny company size.

React is a great example of prioritizing clarity over file size. It’s not a small library – React 0.14.5 + React DOM is 133KB – and I don’t think React ever advertised its file size. But React still manages to become the most widely adopted JavaScript framework in the last few years.

It gained popularity not because of file size but its unique advantages: the simplicity and clarity of the programming model that it enables. In fact, if React is reducing anything, it’s the API surface area, which is a much better (and harder) thing to focus on that reducing the library’s file size.

React is also a great example of showcasing that good documentation, the “how this project works” part, is an important factor of success. Over the years React has accumulated a robust documentation archive filled with concise examples. It also has great community support and educational resources.

Comparing that to Webpack and Bluebird, two otherwise great JavaScript libraries that are often criticized for their horrible documentations, the difference is staggering.

Side note: Personally, I believe it doesn’t make sense for Facebook to focus too much energy on React’s file size. A common justification for React’s file size is it’s doing lots of heavy-lifting behind the scenes. The framework is designed specifically for complex, highly interactive applications. For such use cases, the benchmark of initial time-to-content is less important than on a static application, say, a personal blog. It might take 2 or 3 seconds to get the first page, but once you’re there any interactions afterwards will be rendered fast, which is Facebook’s use case.