ES modules are terrible
gist.github.com
ES modules are terrible
1–10 of 175 posts
Re: ES modules are terrible
#2I 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.
Re: ES modules are terrible
#3TL;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
Re: ES modules are terrible
#4> 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.
That's not true with skypack, right?
Re: ES modules are terrible
#5TL;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"));
Re: ES modules are terrible
#6TL;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/
Re: ES modules are terrible
#7I 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, code duplication inside the modules, long-term cacheability etc.
Re: ES modules are terrible
#8First you create problem with an article, then you fix it with your own magic tool, bravo!
Re: ES modules are terrible
#9TL;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/
inline require is most likely a bad design, imo
Re: ES modules are terrible
#10TL;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…
> lazily loaded imports are both missing from the ES Modules spec.
What do you mean?