ES modules are terrible

> 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 that is inherent in dynamic imports, which by the way, ESM also supports with its dynamic…

I disagree. What we gained is a native module system that works the same everywhere (Nodejs, browsers, deno, Bun) vs CommonJS which was really only built for Nodejs (with compatibility layers for others). We have a specification for this system and any changes done to it have to follow the same process as any other change done to the language (for better or worse). We have top-level async support that works across import boundaries. This is less useful on the…

ES modules are cancer. I'm fine w the syntax — in fact, I love the syntax. But if you use "module: true" in your package.json, you are splitting the npm ecosystem into two groups, and it's not moving us forward.