Many small files vs fewer larger files: impact on bundle size and build time

Question

I've been a relentless proponent of small files. I prefer one function export per file, functions with everything-in-one-view, and breaking up UI components as much as sensible (which is why I love React).

There are many benefits to this from a code-maintenance and clarity perspective (IMO), but I have never assessed what the impact may be on overall bundle size and compilation time (Webpack is tagged here, but other build tools are applicable). My assumption has always been that the benefit of small files is worth what is probably a minor or even negligible difference in bundle size and speed. But I would like some data to back up or refute this assumption without having to massively refactor an existing app for comparison.

So, what is the impact of many-small vs fewer-larger files on bundle size and compilation time?

Answer 1

There are really two separate, but closely related questions here. First is the question about bundle size, and the second is about the time it takes to build the bundles.

Bundle size, and by this I assume you mean the resulting size of the JavaScript file, is not likely to be very relevant. Most transpilers have the option to minify or obfuscate the source code, which reduces file size. Most web servers should be configured to deliver static text assets like CSS and JavaScript as compressed files, which further reduces file size. The concern about bundle size is likely to be premature optimization.

The second concern about the length of time it takes to transpile these files: how long does it really take? Fives seconds? Ten seconds? How long is too long? And better yet, how much will it cost to pay engineers to micro optimize the build process compared to giving developers and/or the build server SSD drives? This is another case of premature optimization. Your time and the company's money is better spent elsewhere.

This is all about performance, and the only solution to performance problems is to measure them. Nine times out of ten the difference in performance is not worth the development time.