Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES modules are terrible

gist.github.com

Post reply on HN
Print view View original

11–20 of 175 posts

Re: ES modules are terrible

#11

Post by wereHamster »

djrockstar1 wrote: post #5
lucideer wrote: post #3

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

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 M…

    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

Re: ES modules are terrible

#12

Post by bricss »

djrockstar1 wrote: post #5
lucideer wrote: post #3

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

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 M…

dynamic imports for that matter, or:

    import { createRequire } from 'module';

    const require = createRequire(import.meta.url);
    const cjsOrJson = require('./somewhat/module/pathway');

Re: ES modules are terrible

#13

Post by Chyzwar »

Problem is bothed node.js implementation that leaves most of existing applications without migration path. Even today it is not possible to create full ESM application front or backend. It is worse than python 2 to 3.

Re: ES modules are terrible

#14

Post by xg15 »

> 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.

I think while OP's right in theory, there is still a lot of difference between the two: ESM has dedicated syntax for static loading of modules and that syntax is strongly communicated to be the standard solution to use if you want to load a module. Yes, dynamic imports exist but they are sort of an exotic feature that you would only use in special situations.

In contrast, CommonJS imports are dynamic by default and only happen to be statically analysable if you remember to write all your imports at the beginning of the module. That's a convention that's enforced through nothing and is not part of the language or even of CommonJS.

As an exercise, try to write a static analyser that simply ignores dynamic imports and just outputs a dependency graph of your static imports - and compare how well this works with CommonJS vs ESM.

Re: ES modules are terrible

#15

Post by theprotocol »

Chyzwar wrote: post #13

Problem is bothed node.js implementation that leaves most of existing applications without migration path. Even today it is not possible to create full ESM application front or backend. It is worse than python 2 to 3.

Absolutely this. It's not necessarily communicated that well in the article, but this is the main reason people are frustrated.

Re: ES modules are terrible

#16

Post by NicoJuicy »

bricss wrote: post #8

First you create problem with an article, then you fix it with your own magic tool, bravo! https://www.npmjs.com/package/fix-esm

Joepie91 did some work for me long ago

If he says there is a problem, he didn't invent it. He knows his stuff

Re: ES modules are terrible

#17

Post by nuerow »

lucideer wrote: post #3

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

> 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.

Re: ES modules are terrible

#18

Post by nrabulinski »

Aeolun wrote: post #6
lucideer wrote: post #3

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

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/

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.

Re: ES modules are terrible

#19

Post by javajosh »

wereHamster wrote: post #7
Aeolun wrote: post #2

I kind of have to agree with the point about loading ESM in the browser. I tried doing this with one of the new fangled frameworks and seeing my browser work through like 5000ish required files was quite comical.

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.

Re: ES modules are terrible

#20

Post by tbrock »

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 wholeheartedly that the end result was a fools errand. I would have rather spent the time adding support for importing types via a require which for some reason returns any “any” today.

Post reply on HN