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

21–30 of 175 posts

Re: ES modules are terrible

#21

Post by noduerme »

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…

Just as an aside... every web app I write these days starts with an index.html page that has a window["deploy"] bool at the top. If that's false, the first script just requires the unbuilt files. If true, it requires the compiled and minified version. I only rebuild when I'm ready to upload.

Re: ES modules are terrible

#23

Post by presentation »

wereHamster wrote: post #11
djrockstar1 wrote: post #5

Earlier quoted context omitted.

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

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

Re: ES modules are terrible

#24

Post by javajosh »

amadeuspagel wrote: post #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. T…

It's important not to ignore the possibility that perhaps front-end dependencies are out-of-hand, and need to be reduced. ESM cannot fix a decade of bad practices enabled by front-end build bundlers. ESM isn't there to be a viable alternative to webpack. It's there to enable a different vision of application deployment where apps are smaller, and javascript gets css's transitive import() sub-resource distribution, avoiding the headache of a linear list of global scripts.

I really like ESM because I like where it's trying to steer the community of browser application builders. I think front-end builds are terrible on many levels, not the least of which is the obfuscation of code that undermines one of the best features of the web's software distribution, which is its openness. And another major benefit of webapps is that none of the front-end languages require a build step! This makes iteration very fast; if you can make do without the the safety net of a compiler, you can enjoy the speed of not using the bundler.

Re: ES modules are terrible

#25

Post by crooked-v »

tbrock wrote: post #20

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

I think you've confused Typescript's own import/export system with ESM. It uses the `import` syntax, but it's not ESM internally, it's its own thing designed to ingest and export to multiple module types.

Re: ES modules are terrible

#26

Post by addicted »

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

Let’s flip this.

What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?

Re: ES modules are terrible

#27

Post by davnicwil »

> 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

This is one of those 'worse is better' things in language design, I believe. It guarantees simplicity, traded off against extra verbosity. In fact, when it comes to the common and probably most valuable case of reading and understanding code written by others quickly, it is not even a tradeoff really, as both are good.

Whether or not that was one of the driving reasons, it certainly is a benefit in my opinion. The two examples given in the post of an inline require don't demonstrate this well, as they're both really simple. I'd say the benefit isn't to stop things examples like that being written and replace them with two lines of code, which admittedly might sometimes be slightly cumbersome. It's that it stops the long tail of much more complex/unreadable statements being written.

Re: ES modules are terrible

#28

Post by theprotocol »

tbrock wrote: post #20

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

The incompatibility is indeed exponentiated with TypeScript.

There is currently no non-hacky way for using both legacy modules and ES Modules in the same project, and many libraries on NPM have moved to ESM-only. TypeScript's transpilation needs to know what to target as regards modules and JS version, which makes things even crazier than they already are.

Re: ES modules are terrible

#29

Post by crooked-v »

javajosh wrote: post #24
amadeuspagel wrote: post #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. T…

It's important not to ignore the possibility that perhaps front-end dependencies are out-of-hand, and need to be reduced. ESM cannot fix a decade of bad practices enabled by front-end build bundlers. ESM isn't there to be a viable alternative to webpack. It's there to enable a different vision of application deployment where apps are smaller, and javascript gets css's transitive import() sub-resource distribution, av…

I think the basic problem with that comparison is that people use bundlers with CSS all the the time for exactly the same basic-physics-of-round-trips reasons. It's common for `import()` in CSS to end up exactly what it usually in frontend JS, a dev organization tool rather than something actually exposed to the browser.

Re: ES modules are terrible

#30

Post by jokethrowaway »

ES Modules was what turned node.js into legacy for me, same as python 2/3.

Plus transpilers are so slow, it's embarrassing (albeit things are improving with tools written in rust).

As someone who's been doing frontend for 20 years and node.js for 10 years, JS development has never been so crap like now.

After attending a conference talk about how the TC39 works, I understand why that's the case. TC39 is basically a bunch of engineers from big tech companies who can afford to waste productivity to follow the whims of whatever the group decide. It's completely detached from reality.

They operate on a full consensus basis, which means everyone needs to be onboard with the decisions - and if you want your changes to be approved in the future, you'd better play nice with the current change as well.

To be honest, I can't wait until browsers get replaced with some native crossplatform toolkit or frameworks in other languages become popular so that we can finally leave JS alone.

Post reply on HN