I like the idea that the browser becomes a native package manager without Node, NPM, or additional build tools.
“This import map is all that is needed to work with dependencies in native modules workflows in browsers, allowing you to get back to focusing on just running your own code natively in the browser, instead of needing to configure complex build tools and package management systems.” [0]
“Import map management becomes a form of package management in the browser.” [1]
top-level esm imports, while cool for some reasons, are basically the same problem as the now rarely used CSS imports, the loading waterfall is basically bonkers. The lazily async loading stuff is neat, and perhaps the big win for the future, but I don’t see how we aren’t just repeating the same mistakes we (as web developers) abandoned a decade ago.
As an experiment at $WORK$ I created a target with a full ESM compliant output to remove all code duplication in an effort to reduce total amount of bytes transferred, and the performance was absolutely horrible. The previous “dumb” minified/bundled js took at most 0.4s on a really bad network, was now a minimum 8s as minified ESM targets on a very good network (I didn’t even bother simulating 3G and such) despite being significantly less total data.
Going forward I don’t think we are going to actually see widespread adoption outside of splitting up monstrous react apps, because as it currently stands it’s super user hostile for library loading. It’s better to just bundle everything and provide an esm target, which negates most of the interesting benefits of ESM as far as I’m concerned.
I like the idea that the browser becomes a native package manager without Node, NPM, or additional build tools.
“This import map is all that is needed to work with dependencies in native modules workflows in browsers, allowing you to get back to focusing on just running your own code natively in the browser, instead of needing to configure complex build tools and package management systems.” [0]
“Import map management becomes a form of package management in the browser.” [1]
[0] https://jspm.org/docs/cdn [1] https://jspm.org/docs/workflows
top-level esm imports, while cool for some reasons, are basically the same problem as the now rarely used CSS imports, the loading waterfall is basically bonkers. The lazily async loading stuff is neat, and perhaps the big win for the future, but I don’t see how we aren’t just repeating the same mistakes we (as web developers) abandoned a decade ago.
As an experiment at $WORK$ I created a target with a full ESM compliant output to remove all code duplication in an effort to reduce total amount of bytes transferred, and the performance was absolutely horrible. The previous “dumb” minified/bundled js took at most 0.4s on a really bad network, was now a minimum 8s as minified ESM targets on a very good network (I didn’t even bother simulating 3G and such) despite being significantly less total data.
Going forward I don’t think we are going to actually see widespread adoption outside of splitting up monstrous react apps, because as it currently stands it’s super user hostile for library loading. It’s better to just bundle everything and provide an esm target, which negates most of the interesting benefits of ESM as far as I’m concerned.