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

91–100 of 134 posts

Re: CommonJS is hurting JavaScript

#91

Post by fndex »

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-compliant code — and for users who get a better end experience."

Re: CommonJS is hurting JavaScript

#92

Post by cypress66 »

BiteCode_dev wrote: post #21
mikece wrote: post #2

[flagged]

Every time this is mentioned, the person is heavily downvoted. But if you were here in the 2000, that's exactly what happened. In fact, this very article starts with "JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past.". That's the first sentence. Nobody wanted to work with JS, it was used to make sno…

> I've yet to met anybody who knows Python/Ruby/C#/Java/Rujst/Go and JS to chose JS outside of the web. Because there, we have the choice.

You probably haven't met many people. For backend you can choose any language, yet a lot of people (with knowledge of many languages) choose JS/TS. I'm one of those.

I enjoy TS more than python.

Re: CommonJS is hurting JavaScript

#93

Post by cxr »

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.

Your "everything" somehow doesn't account for stuff that wasn't written in NodeJS's standards-incompatible way to begin with.

Re: CommonJS is hurting JavaScript

#94

Post by reactus »

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 ~10x less popular than the CommonJS version[1]. The results of these changes broke a lot of code and resulted in many hours of developers figuring out how make their projects compatible with Pure ESM modules (or decide to ignore them and use old CommonJS versions)--not to mention the tons of pointless drama on GitHub issues.

Meanwhile, TC-39 member Matteo Collima advocated a moderate approach dependent on where your module will be run [2]. So the crusade is led not by the Church, but by a handful of zealots dedicated to establishing ESM supremacy for unclear reasons (note how Sindresorus' gist lacks any justifications and how weak TFA's justifications are). It's kind of like the Python 2 to 3 move except with even less rationale and not driven by the core devs.

0 - https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...

1 - https://www.npmjs.com/package/node-fetch?activeTab=versions

2 - https://github.com/nodejs/node/issues/33954#issuecomment-924...

Re: CommonJS is hurting JavaScript

#95

Post by WorldMaker »

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 that don't mind slower hydration outside certain fast paths).

Also, even some cases with bundlers, some of the modern bundlers (esbuild and swc) are still directly bundling to ESM now as the target. Lazy-loading boundaries and common/shared-code boundaries are just ESM imports and there's no "runtime emulation" there, just native browser loading at that point. They are just taking "small" ESM modules and making bigger ones.

Re: CommonJS is hurting JavaScript

#96

Post by attractivechaos »

I dislike CommonJS for a different reason: questionable "fs" module. This module mixes file I/O with file system accesses, which is confusing. More importantly, it does not provide line reading in a synchronous way. I sometimes work with multiple files simultaneously and need to control which file to read. It is awkward to do that with async APIs. Influenced by CommonJS, dart is similar. This ruins large text file processing. Most other languages can read a file line by line in a synchronous way.

Re: CommonJS is hurting JavaScript

#97

Post by [deleted] »

BiteCode_dev wrote: post #21
mikece wrote: post #2

[flagged]

Every time this is mentioned, the person is heavily downvoted. But if you were here in the 2000, that's exactly what happened. In fact, this very article starts with "JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past.". That's the first sentence. Nobody wanted to work with JS, it was used to make sno…

[deleted]

Re: CommonJS is hurting JavaScript

#98

Post by rektide »

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 to esm. Imo it's a pity ecmascript never stabilized a module registry, that esm 1.0 shipped & most people thought it would happen; it's long felt like a bait & switch. But it wasn't a feature browsers needed or really wanted so that unfulfillment was unsurprising. Anyhow, IMO Matteo is making a technical point that it's still hard to finish the move, which is a different spin IMO than a "advocated a moderate approach".

Given the hurt we legitimately experience, I really wish Node and/or WinterCG or someone would prioritize figuring out & implementing whatever needs to go into a module registry/loader. And then beg the big tool chains that need this stuff to expedite their migrations, pretty pretty please.

Re: CommonJS is hurting JavaScript

#99

Post by striking »

qbasic_forever wrote: post #52
striking wrote: post #4

That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.

I did not perceive an aggressive tone from the article, I think you are projecting your annoyance with the Jest project and your architecture choices.

I can't tell you your perception is wrong, but I generally don't unload ornate rhetoric like "insidious saboteur" or verbs that relate to strong imagery like "rip out", "bury" when writing about code unless I intend for my tone to be aggressive.

My code works fine and the article isn't doing itself any favors by mocking me (heh) for thinking so.

Re: CommonJS is hurting JavaScript

#100

Post by Tade0 »

no_wizard wrote: post #3

Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…

> Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers?

I only started my career in ernest in 2012, but even then compatibility with old versions of IE was a major point, due to their high market share.

IE6 was officially retired in 2014, but even then it still accounted for 4.2% of the traffic:

https://www.computerworld.com/article/2488448/ie6--retired-b...

Then there were IE8-11, but it was IE6 which lingered way past its welcome, considering it was originally released in 2001.

Post reply on HN