3 ms·

I think it’s a good question, and the answer isn’t quite as straightforward as you suggest. The advantage of bundling is that you can do cross-module minificat

I think it’s a good question, and the answer isn’t quite as straightforward as you suggest. The advantage of bundling is that you can do cross-module minification and dead-strip unused code. The extreme version of “multiple bundles” would be to minify each JS module individually, but don’t bundle them. That would clearly miss a lot of size optimisations. (And as I understand it, this is how Deno’s new package manager is meant to work, which makes me a bit suspicious.) The opposite extreme of one bundle for the entire app is great for optimisation, but as you say, then you have to invalidate the whole thing if anything changes. One bundle per route is tempting but then common code gets duplicated. Vite’s default behavior (via Rollup) is to make one bundle per common module. That works pretty well but I’ve found the number of output bundles can explode in surprising ways. In a recent project I manually split the code into chunks and loaded them via dynamic import() and that worked pretty well -- good balance of size optimisation, caching and manual control.

jgalt212 3y ago
This is probably some big hairy statistical optimization problem. 100 bundles across 1,000 routes. How to you pack up the 100 bundles into n (n<100) larger bundles such that average time to interactive is smallest. Of course, you get different answers depending on first time vs returning site visitors.
rimunroe 3y ago
Thanks for the thorough reply! I confess I wasn't thinking about a particular build tool. My recent experience has been with Vite, where I took a similar approach to what you describe, but haven't had to dig deep into bundle performance because that's not a bottleneck for our application. The last time I did deeper work on the subject was years ago with Webpack. I thought Webpack at least did dead-code elimination before splitting things into chunks. If I'm reading this random GitHub issue[1] right (and the asker is also right), Webpack does partially behave as I expected, but the pre-chunking optimization pass occurs before things like constant expression evaluation. [1] https://github.com/webpack/webpack/issues/16672 https://github.com/webpack/webpack/issues/16672

jgalt212 3y ago

This is probably some big hairy statistical optimization problem. 100 bundles across 1,000 routes. How to you pack up the 100 bundles into n (n<100) larger bundles such that average time to interactive is smallest. Of course, you get different answers depending on first time vs returning site visitors.

rimunroe 3y ago

Thanks for the thorough reply! I confess I wasn't thinking about a particular build tool. My recent experience has been with Vite, where I took a similar approach to what you describe, but haven't had to dig deep into bundle performance because that's not a bottleneck for our application. The last time I did deeper work on the subject was years ago with Webpack. I thought Webpack at least did dead-code elimination before splitting things into chunks. If I'm reading this random GitHub issue[1] right (and the asker is also right), Webpack does partially behave as I expected, but the pre-chunking optimization pass occurs before things like constant expression evaluation. [1] https://github.com/webpack/webpack/issues/16672 https://github.com/webpack/webpack/issues/16672