This post was adapted from an earlier Twitter thread.
It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.
It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)
And then there's Rollup, which apparently requires ESM to be used, at least to get things like treeshaking. Which then makes people believe that treeshaking is not possible with CommonJS modules. Well, it is - Rollup just chose not to support it.
And then there's Babel, which tried to transpile import
/export
to require
/module.exports
, sidestepping the ongoing effort of standardizing the module semantics for ESM, causing broken imports and require("foo").default
nonsense and spec design issues all over the place.
And then people go "but you can use ESM in browsers without a build step!", apparently not realizing that that is an utterly useless feature because loading a full dependency tree over the network would be unreasonably and unavoidably slow - you'd need as many roundtrips as there are levels of depth in your dependency tree - and so you need some kind of build step anyway, eliminating this entire supposed benefit.
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 import()
syntax. So it doesn't solve that either! Any static analyzer still needs to deal with the case of dynamic imports somehow - it's just rearranging deck chairs on the Titanic.
And then, people go "but now we at least have a standard module system!", apparently not realizing that CommonJS was literally that, the result of an attempt to standardize the various competing module systems in JS. Which, against all odds, actually succeeded!
... and then promptly got destroyed by ESM, which reintroduced a split and all sorts of incompatibility in the ecosystem, rather than just importing some updated variant of CommonJS into the language specification, which would have sidestepped almost all of these issues.
And while the initial CommonJS standardization effort succeeded due to none of the competing module systems being in particularly widespread use yet, CommonJS is so ubiquitous in Javascript-land nowadays that it will never fully go away. Which means that runtimes will forever have to keep supporting two module systems, and developers will forever be paying the cost of the interoperability issues between them.
Is it really? The vast majority of people who believe they're currently using ESM, aren't even actually doing so - they're feeding their entire codebase through Babel, which deftly converts all of those snazzy import
and export
statements back into CommonJS syntax. Which works. So what's the point of the new module system again, if it all works with CommonJS anyway?
And it gets worse; import
and export
are designed as special-cased statements. Aside from the obvious problem of needing to learn a special syntax (which doesn't quite work like object destructuring) instead of reusing core language concepts, this is also a downgrade from CommonJS' require
, which is a first-class expression due to just being a function call.
That might sound irrelevant on the face of it, but it has very real consequences. For example, the following pattern is simply not possible with ESM:
const someInitializedModule = require("module-name")(someOptions);
Or how about this one? Also no longer possible:
const app = express();
// ...
app.use("/users", require("./routers/users"));
Having language features available as a first-class expression is one of the most desirable properties in language design; yet for some completely unclear reason, ESM proponents decided to remove that property. There's just no way anymore to directly combine an import
statement with some other JS syntax, whether or not the module path is statically specified.
The only way around this is with await import
, which would break the supposed static analyzer benefits, only work in async contexts, and even then require weird hacks with parentheses to make it work correctly.
It also means that you now need to make a choice: do you want to be able to use ESM-only dependencies, or do you want to have access to patterns like the above that help you keep your codebase maintainable? ESM or maintainability, your choice!
So, congratulations, ESM proponents. You've destroyed a successful userland specification, wasted many (hundreds of?) thousands of hours of collective developer time, many hours of my own personal unpaid time trying to support people with the fallout, and created ecosystem fragmentation that will never go away, in exchange for... fuck all.
This is a disaster, and the only remaining way I see to fix it is to stop trying to make ESM happen, and deprecate it in favour of some variant of CommonJS modules being absorbed into the spec. It's not too late yet; but at some point it will be.
Not true. You can't
require
. You can run ES5 code in any interpreter without changes. That's what "superset" means, and history has shown over and over that it's the better way to evolve. Providing an alternate mechanism that requires rewriting the code is not the same at all. The larger the superset, the larger the chance that there is some small mistake, but intent matters, and ESM's intent was to nuke the ecosystem and be "revolutionary".They succeeded.
As a comparison, arrow functions are better than the
function
keyword in every way. They have no binding ofthis
issues. They don't have broken hoisting that allows referencing values before initialization. Every value they reference is statically analyzable. They're better. I wish everyone would just stop usingfunction
. However, when they were introduced, they didn't just remove thefunction
keyword, because that would cause a python2 fiasco. Entire codebases would have required rewrites. In short, it would break things, and that breakage would mean poor adoption.Whether you agree about arrow functions is not the point (and I in no way mean to sidetrack this thread on that); it's merely an example of why forcing incompatible changes across an ecosystem are harmful, even if you're ever-so-certain that the new way is better.
Whether commonjs was an "official" standard or not, it was a de facto standard. For the first time in 15 years, the ecosystem had overwhelmingly settled on a module system, because there was finally a sorely-needed package manager. For 5+ years, you had a state of:
You can point out its flaws, but regardless, the new, "better" thing should have tipped a hat and been compatible. It wasn't, and here we are 8 years later with horrible adoption rates.
The most prolific advocate of ESM started forcing this a few years ago. His projects mostly look like this:
TypeScript quite happily converts all of those to commonjs by default. The syntax isn't the issue. It would be trivial to add support for import/export syntax without changing the underlying module architecture. But they did. They made asynchronous loading a requirement, and it was completely unnecessary.
It could have been that:
Browsers could load it asynchronously. Node could load it synchronously. It would have taken a couple of days to implement in node, rather than years. It doesn't matter in the end; you can't use dependencies within a file until those dependencies are loaded. ESM unnecessarily pushed it into the spec. It was based on this pipe dream that we could all just start shipping code without transpiling or bundling, and your files could just import other files via tens of thousands of calls over the network. However:
This would preclude top-level await, which would break... absolutely nothing. Side effects on load are a terrible pattern anyway; you should be able to preemptively load modules. There should be only one file that does that, which is the entry point. The rest should export a function that the importing file can call. If you have async effects as a result of
import 'some-file.js'
, then you have no error handling for the file rejecting its load anyway. The language has no syntax for "Promise
that can't reject", so why would you even want to take away the caller's ability to deal with it and proceed?At the end of the day, most of the decade-long debate has been about the syntax. The syntax is the easy part. In fact, I would guess that at least half of those who are advocates of ESM based solely on the syntax aren't even aware that their code is being transpiled to commonjs anyway. Unless you depend on top-level await, you would never know the difference.
And finally, some common misconceptions:
await import(someVariable)
just as you canrequire(someVariable)
. Both have to deal with it being something you can't statically analyze, and likely both should have linting rules that say "do you realize you're about to break a bunch of things?"