4 ms·

Maybe I’m misunderstanding your question but why would you want a single bundle vs multiple bundles? If you have a single blob you have to invalidate the whole

Maybe I’m misunderstanding your question but why would you want a single bundle vs multiple bundles? If you have a single blob you have to invalidate the whole thing when it updates. If you split your code out into multiple bundles you can invalidate only the bundles which contain changes. As far as I know this has been standard practice for the last decade at least.

iainmerrick 3y ago
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
We have a single bundle of JavaScript with all our helper functions, then a page specific bundle that uses some of the helper functions. The same helper function bundle is delivered to all pages--not a different tree-shaken version delivered to each page that only has the functions used by that page. One helper function bundle is bigger, but since every page gets it, this bundle is code cached.

iainmerrick 3y ago

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

We have a single bundle of JavaScript with all our helper functions, then a page specific bundle that uses some of the helper functions. The same helper function bundle is delivered to all pages--not a different tree-shaken version delivered to each page that only has the functions used by that page. One helper function bundle is bigger, but since every page gets it, this bundle is code cached.