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

1–10 of 134 posts

Re: CommonJS is hurting JavaScript

#3

Post by no_wizard »

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 preceding formats that we couldn't have standardized on them

EDIT: I know about the deal with CommonJS being synchronous. That isn't per se an issue I don't think, esp. because AMD built on top of CommonJS primitives, and with minimal refactoring CommonJS code could be used in the browser when defined this way if asynchronicity is a must. Generally, what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code. This isn't terribly different from how import statements work today.

I'm wondering why we didn't undertake the work to just improve the existing format, more or less.

EDIT 2: I'm interested from a historical perspective. I think ESM is the right choice and 100% the future.

Re: CommonJS is hurting JavaScript

#4

Post by striking »

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.

Re: CommonJS is hurting JavaScript

#8

Post by remexre »

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…

the import syntax makes it possible for the browser to start loading dependencies as soon as the module has been parsed, before it finishes being compiled. the require function would force the browser to download the script being depended on then and there, and since it's not async, the browser would need to pause script execution while the module is being loaded.

Re: CommonJS is hurting JavaScript

#9

Post by shadowgovt »

mikece wrote: post #2

[flagged]

Probably, but that didn't happen and here we are. JavaScript and the DOM are the language and API to manipulate page content, be it directly or as a compilation target.

(Me, I use them as a compilation target, so arguments like the ones in this article are about as interesting to me as arguments about whether the security rings in the next iteration of CPUs are appropriate for modeling proper access constraints).

Re: CommonJS is hurting JavaScript

#10

Post by blowski »

mikece wrote: post #2

[flagged]

> Heck, if MSFT had made VBScript available without license in browsers other than IE I think JavaScript would be an obscure footnote in history.

And we’d be moaning about how bad VBScript is, and how we wish another language had won.

Post reply on HN