HTTP2 solves the loading multiple dependencies in parallel part of the equation, but as far as I can see, the browser would still have to download each dependency before they can resolve their transitive dependencies, so wouldn't this suffer latency issues due to requiring as many sequential client-server roundtrips as the max depth of your dependency tree?<p>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.<p>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.<p>Also somewhat related: the project maintainers for SystemJS and JSPM also provide a CDN at <a href="https://jspm.io/" rel="nofollow">https://jspm.io/</a> 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.<p>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).
This has been the biggest thing holding back wide adoption of native ES modules: every single one of your dependencies has had to be a proper, browser-compatible module. Very exciting.
I'm very curious how you could possibly avoid code bloat with this. Installing hundreds of megabytes of dependencies is fine server side, but won't this approach lead to massive JS downloads?
Wow, they claim that this is equal to or better than most apps that are bundled into a single bundle file due to the cache benefits!<p>I never would have guessed they could manage that and keep it this easy to use!<p>How common is the es module entry point in major packages?
This is brilliant for my efforts to just get started with THREE.js. I gave up due to module dependencies first time around, now I can actually get over that hurdle and get on to what I had planned to do with THREE.js maybe to do things the proper, optimised way with Browserify once I have some feasibility study done on my localhost where I don't care about it being more than a rough prototype.
I was excited but it looks like it'll break Typescript's module resolution. I'm sure someone will come up with something in time, but this is the same story over and over with web development this side of 2016. Nothing works together.