[TekMol]

    tell me that doesn't improve load times

It will negatively impact load times.

Either you only bundle what is needed on the current page. Then the next page will load slower because it needs to bundle all those modules again as it uses a slightly different set of modules.

Or you bundle everything used on any page your users might go to during their session. This will give you a giant blob that has to be loaded upfront which contains a ton of modules the user never need during their browsing session.

[martpie]

That's true if you create your own bundle yourself. Famous frameworks like Next.js or Nuxt make much smarter bundles, with common dependencies grouped together, and bundling the rest by page/view, then loading each bundle when needed.

[jakelazaroff]

It’s still a tradeoff, though. Let’s say a website has three pages: /a, /b and /c. Two of those pages, /a and /b, each use the module `foo`. Where should `foo` get bundled? If you put it in the “common” bundle, it’ll get served to /c even though it’s not needed. If you put it in both of the bundles for /a and /b, the client will download it twice.

[eyelidlessness]

Most bundlers:

- have more sophisticated dependency tracking and will split a separate chunk for a/b

- can produce some kind of a manifest to allow you to preload and avoid nested waterfalls

- provide some mechanism for greater control over what gets chunked separately or combined, for the usage/caching scenarios you’ll undoubtedly know better than a general purpose program

[wruza]

You don’t have to have a single bundle or just main one and common one. Split into as many as you (or a bundler) see fit. In the worst degenerate case you’ll end up with every module bundled separately and preloaded on every page, just like ESM, but without deferred roundtrips for nested dependencies.