ES modules are terrible • Hacker News Board

Re: ES modules are terrible

#171

Post by wruza » Mon, Nov 08, 2021, 4:33 AM UTC

lucideer wrote: post #139

joepie91_ wrote: post #87

Earlier quoted context omitted.

This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.

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

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. No notable difference for static checks, promises are everywhere in javascript.

Re: ES modules are terrible

#172

Post by wruza » Mon, Nov 08, 2021, 4:45 AM UTC

jakelazaroff wrote: post #113

martpie wrote: post #106

Earlier quoted context omitted.

That's true if you create your own bundle yourself. Famous frameworks like Next.js or Nuxt make much smarter bundles, with common dependencies grouped together, and bundling the rest by page/view, then loading each bundle when needed.

It’s still a tradeoff, though. Let’s say a website has three pages: /a, /b and /c. Two of those pages, /a and /b, each use the module `foo`. Where should `foo` get bundled? If you put it in the “common” bundle, it’ll get served to /c even though it’s not needed. If you put it in both of the bundles for /a and /b, the client will download it twice.

You don’t have to have a single bundle or just main one and common one. Split into as many as you (or a bundler) see fit. In the worst degenerate case you’ll end up with every module bundled separately and preloaded on every page, just like ESM, but without deferred roundtrips for nested dependencies.

Re: ES modules are terrible

#173

Post by eyelidlessness » Mon, Nov 08, 2021, 6:34 AM UTC

The reason ESM is better than CJS or any other JS module system is because of the export keyword. Any discussion focused on imports is relevant but missing the significance of ESM.

Re: ES modules are terrible

#174

Post by terracottage » Mon, Nov 08, 2021, 12:49 PM UTC

The worst part is default imports and the linting nazis who want you to use them.

1 file per thing is midwit code organization strategy for people with no actual sense for it.

Re: ES modules are terrible

#175

Post by spankalee » Mon, Nov 08, 2021, 7:02 PM UTC

wruza wrote: post #157

spankalee wrote: post #110

This post is terrible, actually. CommonJS was never going to be natively supported in browsers. The synchronous require semantics are simply incompatible with loading over a network, and the Node team should have known this and apparently (according to members of TC39 at the time) were told their design would not be compatible with future a JS module standard. So the primary thing that JS modules fix is native suppor…

That’s a nice move you do here. Node claimed guilty for implementing the least sucking module system at the time, then growing its NPM size to the skies, and now when there is a ready-to-use module for every task out there, let’s raise a finger and claim they were doing it wrong. Uh oh. Web standards are goddamn late for 20 (twenty) years and it’s not their moral right to decide what should be broken or deprecated, s…

So what would you have had TC39 do, just never standardize a module system because Node made one first that was incompatible with the web?