SystemJS & JSPM has been around for quite a while now, and the goals are similar to this project (to enable loading of any NPM dependency as native ES modules in the browser). They solve the roundtrip problem using an import map that's generated by JSPM to pre-resolve all transitive dependencies, so they can be loaded by the browser up front with maximum parallelism.
However, this project specifically calls out the lack of a need for an import map in its description as an advantage, so I'm wondering if they have some alternative solution to this problem.
Also somewhat related: the project maintainers for SystemJS and JSPM also provide a CDN at https://jspm.io/ serving jspm packaged ES modules for all npm packages, so you can load them as native ES modules with a module script tag or native dynamic import() call in supported browsers. But they specifically mention that this CDN is meant for quick prototyping/experimentation, and not suitable for production use due to latency issues, and recommend bundling workflows for production.
I've been following the SystemJS and JSPM projects for quite a while now, and I feel it's a much better solution for module loading than webpack and the likes that hack together their own non-interoperable proprietary module loader rather than supporting and advancing the official ES module loading standard. But unfortunately that's where the community is at, and SystemJS and JSPM has never been able to reach that critical mass of essential dev tooling that webpack & others have enjoyed for quite some time (the major road block I ran into the last time I tried it was the lack of a good hot module replacement story for development targeting the latest SystemJS 2.0 environment).
The endgame of that train of thought is something like https://mariusgundersen.net/module-pusher/
tl;dr: a smart server can start pushing dependencies as soon as the request for a module comes in.
Even with HTTP/1, the browser will handle a response that came before the matching request.
I never would have guessed they could manage that and keep it this easy to use!
How common is the es module entry point in major packages?
@pika/web's installation most closely matches the study's moderate, "50 file" bundling strategy. Jung's post found that for HTTP/2, "differences among concatenation levels below 1000 [small files] (50, 6 or 1) were negligible."
I've not had a need to do much JavaScript since the days when you just directly used a few external libraries via <script>, so this just sounds nuts to me.
I suppose it's probably common, and the various packers make it work fine, but wow.
Then it’s available in the window.THREE object, it’s not the “most correct” way but it’s great for prototyping
> By default, @pika/web will install all package.json dependencies with an ES "module" entrypoint to the web_modules/ directory. @pika/web is able to handle any legacy Common.js/Node.js transitive dependencies in your dependency tree, however the top-level dependencies (the ones that you import directly) must have a "module" entrypoint.