4 ms·
As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module sy
by o11c 2y ago
As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module systems have.
- jazzypants 2y agoWhich features?
- o11c 2y agoConditional imports (e.g. depending on browser-version, browser-vs-server) is the big one. This does not inhibit the alleged static analysis goal at all, but the specification is pointlessly hostile to it. I would've expected the "import assertions" proposal to cover this obvious problem, but no, it's just another useless thing that will always have to be transpiled into nonexistence. Transparent polyfills (or anything that really needs to be loaded "first") also don't work, since async means you can't specify the order to load things. This means that every single module you write has to explicitly mention which exact polyfill it's going to end up using (hope you don't accidentally skip one or specify a conflicting polyfill) ... or you just abandon modules and load your polyfills with a normal script (which means that now your source is a bastard mixture). Lazy imports are technically possible via dynamic imports, but unnecessarily annoying and break in all sorts of places. Granted, the standardization of the "leaky browser abstraction" makes this pretty awful regardless.