I really don't get the point the author is trying to make.<p>The fact that Babel is often used to transpile ES modules to CommonJS says nothing about whether ES modules are terrible; it mostly speaks to the state of the Node.js community, and perhaps the state of bundling applications for the web. It's possible to use pure ES modules <i>today</i> in Node.js, Deno, and in the browser; it just may mean that whatever Node.js package you want to use won't make that easy (without something like JSPM.io).<p>As far as lacking advantages over CommonJS, I don't know what he's talking about either. ESM is much more practical to statically analyze given that it's a language feature and not a function that just happens to be in the global scope. If ESM was more of a copy of CommonJS, the author would probably be complaining that it doesn't support static analysis or tree shaking.<p>Those aside, the use of the word "terrible" comes across as insincere. ES modules are not complicated. They have their own scope and they can have exports that can be imported elsewhere. If there's any other detail or behavior I didn't mention, my guess is that it's barely important. In my experience, modules work quite well and are an essential language feature. The fact that they have their own scope is particularly nice given that there are many other languages that don't give their modules their own scope by default.<p>The author wants import syntax to both support static analysis and call it as a function within any JavaScript expression, yet they provide no example of a hypothetical syntax that would make this possible. Those needs are <i>necessarily</i> in conflict. In other words, the author wants to eat their cake and have it too. As they point out, ESM <i>does</i> provide an import function that can be called this way, but the author is annoyed that it's async and may require parentheses (which they believe is a "weird hack" for some reason).<p>Making the `import` function async is a good design choice. In the browser, which is JavaScript's natural habitat, importing is necessarily async because other modules have to be fetched as separate files via HTTP. If it weren't async, we'd be stuck bundling "modules" together with Webpack, which goes against what the author actually seems to want, which is actual modules. In runtimes like Deno, being able to asynchronously import from URLs on the backend is pretty nice as well. CommonJS doesn't support this without something more akin to a "hack" than the parentheses "hack" the author complains about.<p>Also, there's some very foolish comments in that Gist. For one, you can't blame ESM because of Typescript. ES doesn't give a hoot about Typescript, nor should it. ES modules "[don't] work in the browser" because of performance? Nothing is stopping you from bundling parts of your application, ESM or not. It's as if http3+ isn't a thing either. In fairness, most JavaScript applications rely far too heavily on a bajillion 3rd party packages, and the answer is we should stop doing this as often or to such degrees.