4 ms·

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

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

crooked-v 5y ago
The total inability to properly mock ES modules without experimental Node flags is a big one. It can turn unit testing into a nightmare if even one ESM dependency creeps in.
djrockstar1 5y ago
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")); Configurable modules and lazily loaded imports are both missing from the ES Modules spec.
- Ginden 5y ago
  > lazily loaded imports are both missing from the ES Modules spec. What do you mean?
- wereHamster 5y ago
  import someModule from "module-name" const someInitializedModule = someModule(someOptions) A bit longer, but meh… const app = express(); app.use("/users", (await import("./routers/users")).default); top-level await is a thing now Actually, the first example could be rewritten as const someInitializedModule = (await import("module-name")).default(someOptions); That «simply not possible» statement is simply not true
  - presentation 5y ago
    Or don’t even bother with the awaited import and instead import it at the top of the file, I fail to see why this is even an issue lol
- bricss 5y ago
  dynamic imports for that matter, or: import { createRequire } from 'module'; const require = createRequire(import.meta.url); const cjsOrJson = require('./somewhat/module/pathway');
Aeolun 5y ago
There is one. Which is that you can’t easily do an inline require any more. The rest of the text can mostly be summarized as https://xkcd.com/927/ https://xkcd.com/927/
- tehbeard 5y ago
  Inline require(...), Are we back to bad old days of PHP include '...'; midway through a classes function already?
- bricss 5y ago
  inline require is most likely a bad design, imo
- nrabulinski 5y ago
  I’ve been working with node for roughly 5 years and I’ve never liked the hackieness CJS let people incorporate. People, especially a few years ago, were trying to get clever with the require calls, were fiddling around with require cache and while with ESM we no longer can “easily” do stuff like dynamic reloads, I genuinely feel it’s for the better. I strongly agree with privatenumber’s point that import() syntax is the true first class citizen here.
nuerow 5y ago
> 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 This. Also, the bulk of the rant is focused on how the author struggles with configuring his pick of JavaScript bundlers and transpilers, and proceeds to come up with excuses to justify not migrating away from CommonJS . This article was a waste of a perfectly good click.
addicted 5y ago
Let’s flip this. What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?
- Ginden 5y ago
  Statically analyzable tree. In CJS you have to depend on people not doing strange things to their `module.exports` and you are left with heuristics.
  - joepie91_ 5y ago
    This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.
    - lucideer 5y ago
      > as I've explained in my article Not convincingly. Firstly, static imports are markedly different to top-level require due to module scoping: e.g. tree-shaking isn't stable with most "statically-analysed" top-level requires due to potential side-effects. Secondly, handwaving dynamic imports as the ES Modules equivalent to non-top-level require doesn't pass the smell test. Dynamic imports are a deliberately separate syntax and mechanism to static imports, whereas require isn't differentiated. They are also, notably, async.
      - wruza 5y ago
        Smell tests are irrelevant to analyzers code. Developers are either able to break analyzers by using import() or are unable. They’re still able with ESM, and they’re still able to deliberately not do that with require(literal). Async has nothing to do with that, all it does is wrapping T into Promise<T>. No notable difference for static checks, promises are everywhere in javascript.
  - wruza 5y ago
    Could you please point to “strange things” that people do with “exports” AND how it prevents static analyzers from doing their job? Why they can do it for: var x = strange_thing() but suddenly can not when “x” is renamed to “exports”?

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

crooked-v 5y ago

The total inability to properly mock ES modules without experimental Node flags is a big one. It can turn unit testing into a nightmare if even one ESM dependency creeps in.

djrockstar1 5y ago

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")); Configurable modules and lazily loaded imports are both missing from the ES Modules spec.

Ginden 5y ago
> lazily loaded imports are both missing from the ES Modules spec. What do you mean?
wereHamster 5y ago
import someModule from "module-name" const someInitializedModule = someModule(someOptions) A bit longer, but meh… const app = express(); app.use("/users", (await import("./routers/users")).default); top-level await is a thing now Actually, the first example could be rewritten as const someInitializedModule = (await import("module-name")).default(someOptions); That «simply not possible» statement is simply not true
- presentation 5y ago
  Or don’t even bother with the awaited import and instead import it at the top of the file, I fail to see why this is even an issue lol
bricss 5y ago
dynamic imports for that matter, or: import { createRequire } from 'module'; const require = createRequire(import.meta.url); const cjsOrJson = require('./somewhat/module/pathway');

Aeolun 5y ago

There is one. Which is that you can’t easily do an inline require any more. The rest of the text can mostly be summarized as https://xkcd.com/927/ https://xkcd.com/927/

tehbeard 5y ago
Inline require(...), Are we back to bad old days of PHP include '...'; midway through a classes function already?
bricss 5y ago
inline require is most likely a bad design, imo
nrabulinski 5y ago
I’ve been working with node for roughly 5 years and I’ve never liked the hackieness CJS let people incorporate. People, especially a few years ago, were trying to get clever with the require calls, were fiddling around with require cache and while with ESM we no longer can “easily” do stuff like dynamic reloads, I genuinely feel it’s for the better. I strongly agree with privatenumber’s point that import() syntax is the true first class citizen here.

nuerow 5y ago

> 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 This. Also, the bulk of the rant is focused on how the author struggles with configuring his pick of JavaScript bundlers and transpilers, and proceeds to come up with excuses to justify not migrating away from CommonJS . This article was a waste of a perfectly good click.

addicted 5y ago

Let’s flip this. What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?

Ginden 5y ago
Statically analyzable tree. In CJS you have to depend on people not doing strange things to their `module.exports` and you are left with heuristics.
- joepie91_ 5y ago
  This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.
  - lucideer 5y ago
    > as I've explained in my article Not convincingly. Firstly, static imports are markedly different to top-level require due to module scoping: e.g. tree-shaking isn't stable with most "statically-analysed" top-level requires due to potential side-effects. Secondly, handwaving dynamic imports as the ES Modules equivalent to non-top-level require doesn't pass the smell test. Dynamic imports are a deliberately separate syntax and mechanism to static imports, whereas require isn't differentiated. They are also, notably, async.
    - wruza 5y ago
      Smell tests are irrelevant to analyzers code. Developers are either able to break analyzers by using import() or are unable. They’re still able with ESM, and they’re still able to deliberately not do that with require(literal). Async has nothing to do with that, all it does is wrapping T into Promise<T>. No notable difference for static checks, promises are everywhere in javascript.
- wruza 5y ago
  Could you please point to “strange things” that people do with “exports” AND how it prevents static analyzers from doing their job? Why they can do it for: var x = strange_thing() but suddenly can not when “x” is renamed to “exports”?