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

CommonJS is hurting JavaScript

deno.com

Post reply on HN
Print view View original

101–110 of 134 posts

Re: CommonJS is hurting JavaScript

#101

Post by wwwigham »

WorldMaker wrote: post #95
wwwigham wrote: post #73

I think this is funny, since esm being "native" on browsers doesn't really matter until you can convince devs they don't actually need to use a bundler. So long as you're using a bundler, the browser's runtime doesn't really matter - you're using the runtime the bundler presents and emulates on the browser. Native ESM has proven to be quite painful in ecosystems that _don't_ rely on the presence of a bundler to patch…

I've seen some great development environments where all of development/debugging is unbundled ESM directly in the browser. It's going to take a lot of momentum shift to swing the "bundler pendulum" back away from "always" to "as needed" (or even, shockingly, "never"), but I think it is going to happen. HTTP/2+ really does make "never" a bigger possibility than ever before, especially in cases like MPAs (and SSR SPAs…

I, too, thought http/2+ would encourage unbundled js, but unfortunately in a world where people are used to whole-program minification and dynamic app slicing, I don't think we'll _ever_ move away from bundlers. The build step is here to stay for most serious projects.

ESM may very well be the module system designed for a world that'll actually never exist, and will mostly just be an ill defined compilation target. But hey, maybe the next web module system will do better - those wasm working group people are working hard on their module system - and it's intended as a compilation target from the start, so shortcomings in it can be patched over by tools from the start :)

Re: CommonJS is hurting JavaScript

#102

Post by rektide »

striking wrote: post #50
photonerd wrote: post #29

Earlier quoted context omitted.

That’s mostly because of how Jest absolutely brutalizes the Require stack. It’s a problem with Jest AND CommonJS, not ES Modules. In fact it’s a very illustrative example of why CommonJS should be taken out back and shot.

Are you saying I just shouldn't have access to that part of the runtime? I've also done my fair share of `require` hacking, and it's led to things like hot reload and lazy loading for Node backends. There's a lot of value in being able to mess with that part of the stack.

I really wish this sort of hackerly mojo was available in the browser too.

Being able to hot reload & instrument modules is power we should have. Will some people greatly mess it up & create hard to maintain software? Oh yes. But let not the bottom of thr curve be an excuse to clip off the top half of the bell curve. Ad Astra.

As esm was being specced out in es2015, there was an expectation there would be follow on work for a registry, where modules could be managed by the runtime.

That never happened. Heck, 2023 and we still don't have actually modular modules in web workers: there's no import-map support or spec! Issue #2 in import maps... 2. https://github.com/WICG/import-maps/issues/2

Re: CommonJS is hurting JavaScript

#103

Post by rektide »

tracker1 wrote: post #39

Didn't see mention of Browserify and other bundlers after it that made CommonJS the defacto standard for client/browser libraries as well. I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependenci…

> I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle.

Huge huge agreement.

I forget the specifics but there was some super tiny corner case around maybe default exports that could potentially create ambiguity & that spawned a multi-year bellyaching around doing anything at all for interop. What Node got was incredibly hard fought for against much resistance to interop.

But the final compromises made everything so much more painful for everyone. So many esm projects but oh look a .eslintrc.cjs, how unsurprising & sad.

It's extra maddening because node had a wonderful just works (except that tiny tiny tiny corner case) interop via @standard-things/esm, which seamlessly let the two worlds interop. It'd been around for years before node started shipping support, and it was no ceremony just works bidirectional interoperability, and it took basically no effort or thought from the developers point of view to use. It sucked seeing us walk back from great, mired by frivolous over concern for a obscure corner-case.

https://github.com/standard-things/esm

Re: CommonJS is hurting JavaScript

#104

Post by reactus »

rektide wrote: post #98
reactus wrote: post #94

Would anyone be interested in an article about the crusade to move JS to ESM? I've been considering writing one, here's a preview: Sindresorus wrote a gist "Pure ESM modules"[0] and converted all his modules to Pure ESM, breaking anyone who attempted to `require` the latest versions of his code; he later locked the thread to prevent people from complaining. node-fetch released a pure ESM version a year ago that is ~1…

ESM was a part of es2015. It's been 8 years that we've had to tangle with both cjs & esm. It's been absolutely awful for everyone. This crusade is nowhere near zealous nor righteous enough against the infidels & non-believers. But it also hasn't been effective enough at supporting/supplying the crusade either. Matteo's statement was that Node hasn't stabilized their loader support so tools have a harm time migrating…

> It's been absolutely awful for everyone.

It only became awful for me when people started publishing pure ESM packages; `npm i node-fetch` suddenly began resulting in broken scripts and I had to learn why. Prior to that, I happily used CJS outside of the browser and what I suppose is ESM in the browser (the `import` syntax provided by bundlers).

> a different spin IMO than a "advocated a moderate approach".

He said, "If your module target the Browser only, go for ESM. If your module target Node.js only, go for CJS."

This is moderate compared to the "Pure ESM" approach. The fetch API is built into browsers so I don't see why anyone would use `node-fetch` outside of Node.js, and yet the maintainers of `node-fetch` went Pure ESM anyway. Also that GitHub issue is titled "When will CommonJS modules (require) be deprecated and removed?" and his response was "There is no plan to deprecate CommonJS"[0].

0 - https://github.com/nodejs/node/issues/33954#issuecomment-776...

Re: CommonJS is hurting JavaScript

#105

Post by briantakita »

rektide wrote: post #102
striking wrote: post #50

Earlier quoted context omitted.

Are you saying I just shouldn't have access to that part of the runtime? I've also done my fair share of `require` hacking, and it's led to things like hot reload and lazy loading for Node backends. There's a lot of value in being able to mess with that part of the stack.

I really wish this sort of hackerly mojo was available in the browser too. Being able to hot reload & instrument modules is power we should have. Will some people greatly mess it up & create hard to maintain software? Oh yes. But let not the bottom of thr curve be an excuse to clip off the top half of the bell curve. Ad Astra. As esm was being specced out in es2015, there was an expectation there would be follow on w…

> As esm was being specced out in es2015, there was an expectation there would be follow on work for a registry, where modules could be managed by the runtime.

I've seen routing architectures that support HMR & runtime management of modules use an Object with methods that call `import('module-name')`. Would dynamic imports be sufficient to support the use case you described?

Re: CommonJS is hurting JavaScript

#106

Post by rglover »

fndex wrote: post #91
rglover wrote: post #58

Shrug I think there should be more praise on these guys for what they accomplished given the state of JavaScript when they started. They saw a problem and came up with a solution. Was it perfect? No, but it's not this abominable creation. Much like John Resig's work on jQuery nudged JavaScript forward, so did the work on CommonJS/Node.

Quoting from the article: "In 2009, CommonJS was exactly what JavaScript needed. The group took a tough problem and forced through a solution that continues to be used millions of times a day. But with ESM as the standard and the focus shifting towards cloud primitives — the edge, browsers, and serverless compute — and CommonJS simply doesn’t cut it. ESM is a better solution for developers, as they can write browser-…

This is what confused me in there (in the sense that the author seems to "get it" as to why CommonJS is still around). All of this ESM stuff has only (relatively) recently started to take shape. To say CommonJS is "hurting" JavaScript though seems overly-reactive. Technological evolution takes time and deep consideration to not create future messes. It's not the most comfortable but we're in the "messy middle" of moving from one to the other.

Re: CommonJS is hurting JavaScript

#107

Post by notnullorvoid »

I agree that CJS needs to go, and the sooner the better. However it's slightly irritating hearing this presented on the Deno blog. Deno is no better when it comes to causing issues for library authors who want to provide cross runtime compatible ESM modules. They bundle their own fork of TS which lags behind TS stable, no support for important things like `typeVersions`, no way to test your library with newer (or older) TS versions. You're better off authoring ESM libraries for Node then telling Deno users to use `npm:` imports.

Re: CommonJS is hurting JavaScript

#108

Post by wdb »

The ESM-only packages like node-fetch are such a pain to work with in Node in a CommonJs project.

I think this forced ESM is causing a lot vulnerabilities in code base due to the pain converting projects to ESM is. I am busy enough to try to get tests pass for some new version of a package that got ESM-only.

Wished they would publish cjs and esm for packages that target Node. Fine you go ESM-only for browser only packages.

Re: CommonJS is hurting JavaScript

#109

Post by lelanthran »

jhp123 wrote: post #15

the benefits of esm are not compelling enough to rewrite everything. Browser-native module loading is a niche use case which can never be as performant as bundling (even if per-request overhead is minimized in http2, a chain of dependencies will lead to excess round trips).

> the benefits of esm are not compelling enough to rewrite everything.

It's rare that standards don't beat out non-standards in adoption.

ESM is the standard; there is only one way this ends,and it's not in favour of CJS.

Re: CommonJS is hurting JavaScript

#110

Post by paulddraper »

rektide wrote: post #98
reactus wrote: post #94

Would anyone be interested in an article about the crusade to move JS to ESM? I've been considering writing one, here's a preview: Sindresorus wrote a gist "Pure ESM modules"[0] and converted all his modules to Pure ESM, breaking anyone who attempted to `require` the latest versions of his code; he later locked the thread to prevent people from complaining. node-fetch released a pure ESM version a year ago that is ~1…

ESM was a part of es2015. It's been 8 years that we've had to tangle with both cjs & esm. It's been absolutely awful for everyone. This crusade is nowhere near zealous nor righteous enough against the infidels & non-believers. But it also hasn't been effective enough at supporting/supplying the crusade either. Matteo's statement was that Node hasn't stabilized their loader support so tools have a harm time migrating…

> ESM was a part of es2015. It's been 8 years

Okay, but let's not resist inconveniencing ourselves with the facts.

ESM got browser support in 2017 and stable Node.js support in 2020.

Post reply on HN