I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero . There is also a cognitive overhead of having to configure the server to push a…
Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published. There would be no reason to further run a bundler just to turn ~5 such pairs of files into one pair. Over HTTP2/3 that difference is negligible.It's non-negligible for "thousands of dependencies", of course, but nobody would be doing that. "Thousands of dependencies" is for library development, not for library release packaging.
NPM (or Pika) is still useful under such a paradigm, for the same reason Cargo or Bundler or Pip or Mix or whatever other tools are useful: these tools let you specify your direct dependencies using symbolic version constraints, and then retrieve+update+lock those dependencies. This is helpful whether your direct dependencies are "baked-down" release packages or raw deep-dep-tree source.