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

71–80 of 134 posts

Re: CommonJS is hurting JavaScript

#71

Post by recursive »

lucacasonato wrote: post #42
geenat wrote: post #36

The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…

If you are same origin, you do not require CORS to use type=module. Also type=module works on HTML pages served from file:// (file:///.../index.html).

It is not possible to do same origin from a file system. Everything served from a file system is considered to be different origins. This drives me bonkers.

Re: CommonJS is hurting JavaScript

#73

Post by wwwigham »

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 over problems, precisely because of the issues of interoping with, I don't know, _literally any existing code_.

I can't think of a concrete benefit to a developer that ESM brings (just pain, but maybe I'm biased by what I'm exposed to). Probably why it's so slow to be adopted.

Re: CommonJS is hurting JavaScript

#74

Post by tracker1 »

tredre3 wrote: post #43
geenat wrote: post #36

The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…

> Shouldn't that be a relative path for it to actually work as you intend?

It just needs to be browser resolvable, assuming this element is meant to run in a browser. So absolute paths do work. For libraries, you may want to use import maps or absolute urls (similar to Deno). There's also esm.sh and jspm.org for modules that are able to be relatively easily converted.

I think it may be necessary/prudent to get some level of JSX support into browsers, much like the ts as comments efforts. Not sure how that will/would land. I was a pretty big fan of E4X, and had a prototype similar to React about a decade before it. In the end, who knows.

Re: CommonJS is hurting JavaScript

#76

Post by briantakita »

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.

Unfortunately, migrations are necessary when major releases occur. At some point, the argument to cling onto old tech which holds back the entire ecosystem needs to be deprioritized. Years have passed already so it should not be a surprise when the ecosystem moves on.

Re mocks, an ecosystem should not be held back solely due to an arcane edge case. The apps that use test doubles can be rearchitected to support test doubles to the programmers' satisfaction. Most people do not use test doubles & the benefits of ESM & not having to deal with CJS outweigh the downsides of losing some convenience in mocking modules.

This is something that will not be popular with clingers to CJS, but it is something that will benefit the wider ecosystem. The vocal minority which is holding back the ecosystem should start making plans to migrate because it is in the process of happening right now...

So I think the general resentment is having to do extra work to support CJS which is not standard across all JS platforms...and some legacy libraries are still written in CJS requiring an interop. So it would be great to not have to do this extra work to support the legacy CJS on Node.js when every other JS platform is using ESM. In this case, one person's convenience comes at a cost to everyone else & at some point, that one person is going to have to suck it up & do the work to support his use case...just as everyone else had to do the work to support the legacy CJS for years now.

Re: CommonJS is hurting JavaScript

#77

Post by [deleted] »

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…

[deleted]

Re: CommonJS is hurting JavaScript

#79

Post by [deleted] »

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.

[deleted]

Re: CommonJS is hurting JavaScript

#80

Post by bastawhiz »

photonerd wrote: post #29
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.

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.

It's a problem with Jest and CommonJS only in so far as it's a problem with mocking in general: native ESM imports are read-only. You can roll your own dependency injection or use tools that parse/rewrite your imports at runtime, but this is hardly a good solution. I think the parent's comment still stands: there's a big gap remaining.
Post reply on HN