31–40 of 175 posts
TL;DR: Breaking backwards compatibility is always painful but there's not one actual criticism of ES Modules as a spec here other than its incompatibility with CommonJS
Let’s flip this. What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?
TL;DR: Breaking backwards compatibility is always painful but there's not one actual criticism of ES Modules as a spec here other than its incompatibility with CommonJS
> And then people go "well you can statically analyze it better!", apparently not realizing that ESM doesn't actually change any of the JS semantics other than the import/export syntax, and that the import/export statements are equally analyzable as top-level require/module.exports. ... "But in CommonJS you can use those elsewhere too, and that breaks static analyzers!", I hear you say. Well, yes, absolutely. But tha…
It may not be as simple, but I venture it's easier to implement than having all the software ever written needing to be migrated
> And then people go "well you can statically analyze it better!", apparently not realizing that ESM doesn't actually change any of the JS semantics other than the import/export syntax, and that the import/export statements are equally analyzable as top-level require/module.exports. ... "But in CommonJS you can use those elsewhere too, and that breaks static analyzers!", I hear you say. Well, yes, absolutely. But tha…
There are web frameworks pushing this pretty hard for basic stuff (for example: loading React components with dynamic import) to build page-content-streaming functionality around it.
A webmaster could totally avoid the complexity of learning a JS tool chain. Right now even 1000 lines of JS has you reaching for a bundler. It would make shipping a small html+css+js site again as simple as dragging files to your webserver.
Don't bundle. The only reason for bundling is too many requests to the server. Use HTTP/2 instead.
We recently went through this hell converting a NodeJS codebase to TypeScript. One reason many people willingly enter this hellscape is because we need ES modules for typescript. I say “need” because Typescript wont ingest types from “required” files, you have to import them as modules. So before we converted a single file to TS we has to audit all commonjs imports and exports to convert them to ES modules. I agree w…
I think you've confused Typescript's own import/export system with ESM. It uses the `import` syntax, but it's not ESM internally, it's its own thing designed to ingest and export to multiple module types.
> And then people go "well you can statically analyze it better!", apparently not realizing that ESM doesn't actually change any of the JS semantics other than the import/export syntax, and that the import/export statements are equally analyzable as top-level require/module.exports. ... "But in CommonJS you can use those elsewhere too, and that breaks static analyzers!", I hear you say. Well, yes, absolutely. But tha…
You can detect from the AST whether a require can be statically resolved or depends on non static variables. It may not be as simple, but I venture it's easier to implement than having all the software ever written needing to be migrated
I can't say how common those forms are, but my point is that there is nothing immediately discouraging a programmer from using them as all of it is "just javascript". So even if you just restrict yourself to static imports, its hard to be sure you caught all of them without running the program.
Earlier quoted context omitted.
Unprocessed ESM in the browser makes sense for local development. We are collectively wasting millions of CPU hours (and developer time) waiting for our mostly unchanging dependencies to be processed. For production deployment though, I'd still prefer ESM in the browser, but not verbatim as they are coming from npm, but compiled, minified, and bundled in a way that strikes a balance between total number of modules, c…
The more people start to internalize the truth that "if you ship it you own it" and stop adding dependencies and start removing them, especially if they come with their own wasteful dependencies, then ESM will make sense for everyone. Until then, you're right, devs have to go through unctuous mitigations.