Busting the Cult of File Size Obsession
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.
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
The heavy-hitters’ elsewhere
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
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.
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.