CommonJS is hurting JavaScript • Hacker News Board

Re: CommonJS is hurting JavaScript

#121

Post by andrew_ » Sat, Jul 01, 2023, 12:30 AM UTC

jacobwg wrote: post #118

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…

I mean, I took Sindre's move to ESM-only publishing as his own choice as the author and maintainer of his own OSS packages. In the spirit of OSS, he doesn't need to justify the choice, it's good enough that as the author he's making it. The previous CJS versions are still published, and anyone can fork the modules if they want to take on the maintenance burden of the CJS version. That preference has had an impact on…

And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions.

I'm working on greenfield projects that leadership is still insisting we avoid ESM-only packages for. The move that Sindre (and others like wooorm) made has not been well-received.

Re: CommonJS is hurting JavaScript

#122

Post by montroser » Sat, Jul 01, 2023, 12:45 AM UTC

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.

Agreed -- the article actually acknowledges this point, but the clickbait title is not very generous.

CJS was doing just fine in Node.js for nearly a decade before ESM came along and made everything more difficult by shoving browser constraints into a server-side runtime. ESM may be the right direction for the whole ecosystem in the long run, but it's a little backwards to say the perfectly good incumbent system is "hurting" the language because everyone who invested in it doesn't want to go through the pain of migrating to a new fashionable system that is worse in many ways.

Re: CommonJS is hurting JavaScript

#123

Post by pjmlp » Sat, Jul 01, 2023, 5:04 AM UTC

andrew_ wrote: post #121

jacobwg wrote: post #118

Earlier quoted context omitted.

I mean, I took Sindre's move to ESM-only publishing as his own choice as the author and maintainer of his own OSS packages. In the spirit of OSS, he doesn't need to justify the choice, it's good enough that as the author he's making it. The previous CJS versions are still published, and anyone can fork the modules if they want to take on the maintenance burden of the CJS version. That preference has had an impact on…

And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions. I'm working on greenfield projects that leadership is still insisting we avoid ESM-only packages for. The move that Sindre (and others like wooorm) made has not been well-received.

Many authors don't care if 5 dudes use their stuff, or the rest of the world, specially when taking zero monetary value out of it.

Re: CommonJS is hurting JavaScript

#124

Post by pjmlp » Sat, Jul 01, 2023, 5:08 AM UTC

My workaround is to use Typescript.

Re: CommonJS is hurting JavaScript

#125

Post by _nalply » Sat, Jul 01, 2023, 6:46 AM UTC

There's an explosion of module types.

Node has cjs and esm, Browser has legacy (create sub-objects in the global or window object) and esm.

I tried to write a polyglot, but was not successful. https://stackoverflow.com/questions/48396968/72314371 proposes a clever polyglot exploiting that await is parsed differently at the top level when in esm or not. However this doesn't help, because import and export keywords always fail hard (not catchable by try-catch) and eval (yuck!) doesn't help because inside eval your are legacy.

So you have to bundle if you want to provide for everybody... (shrugs)

Re: CommonJS is hurting JavaScript

#126

Post by dwild » Sat, Jul 01, 2023, 8:15 PM UTC

andrew_ wrote: post #121

jacobwg wrote: post #118

Earlier quoted context omitted.

I mean, I took Sindre's move to ESM-only publishing as his own choice as the author and maintainer of his own OSS packages. In the spirit of OSS, he doesn't need to justify the choice, it's good enough that as the author he's making it. The previous CJS versions are still published, and anyone can fork the modules if they want to take on the maintenance burden of the CJS version. That preference has had an impact on…

And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions. I'm working on greenfield projects that leadership is still insisting we avoid ESM-only packages for. The move that Sindre (and others like wooorm) made has not been well-received.

> And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions.

You write this as if that mattered...

Should he only works on stuff that gets more download? For what reasons? He works on what he wants to works on, it's amazing and he is lucky to be able to do it.

> The move that Sindre (and others like wooorm) made has not been well-received

It's normal to be sad to have lost someone that was working on something you needed, but anything else is just entitlement.

Re: CommonJS is hurting JavaScript

#127

Post by nicolae_g_iotu » Sun, Jul 02, 2023, 3:02 PM UTC

My opinion is that a moderate approach is required, maybe a new solution needs to be discovered.

I think ESM modules are most of the times desirable by developers of small to mid size packages. These developers want to have their packages used both on server and in browser.

On the other side heavy duty packages which are able to generate production loads (see Fastify) should use CommonJS. In my opinion production loads should not have importable elements, stay private and rather just run and get the job done. At the same time it is really not that important for such loads to have good loading times for the micro packages used.

This is debatable, but yet another aspect to consider: server side production loads must use CommonJS.

Re: CommonJS is hurting JavaScript

#128

Post by nicolae_g_iotu » Sun, Jul 02, 2023, 4:33 PM UTC

I just realized that programmers of production loads can quickly switch to ESM. Just perform a global replace of 'require' using 'import'.

What's actually preventing this from happening is the fact that not all official packages are ESM ready.

So the solution might be actually very easy. Set a deadline for the implementation of ESM and send frequent notifications to developers.

After the deadline all those running production loads will have to switch to ESM syntax when updating. This seems facile and organized.

Re: CommonJS is hurting JavaScript

#129

Post by andrew_ » Sun, Jul 02, 2023, 7:26 PM UTC

dwild wrote: post #126

andrew_ wrote: post #121

Earlier quoted context omitted.

And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions. I'm working on greenfield projects that leadership is still insisting we avoid ESM-only packages for. The move that Sindre (and others like wooorm) made has not been well-received.

> And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions. You write this as if that mattered... Should he only works on stuff that gets more download? For what reasons? He works on what he wants to works on, it's amazing and he is lucky to be able to do it. > The move that Sindre (and others like wooorm) made has not been well-received It's normal to be sad to have…

> You write this as if that mattered... Should he only works on stuff that gets more download?

It was a statement of fact. You appear to be drawing conclusions that were never hinted at nor implied. It's tiresome.

> It's normal to be sad to have lost someone that was working on something you needed, but anything else is just entitlement.

How and why are you applying entitlement and emotion to a documented statement of fact? Do you need to see links such as [1] to view that as fact? It's one of a myriad. Take your asinine analysis and commentary elsewhere, please.

[1] https://github.com/sindresorhus/meta/discussions/15

Re: CommonJS is hurting JavaScript

#130

Post by andrew_ » Sun, Jul 02, 2023, 7:28 PM UTC

pjmlp wrote: post #123

andrew_ wrote: post #121

Earlier quoted context omitted.

And yet his older CJS versions get weekly downloads that are magnitudes higher than the newer ESM versions. I'm working on greenfield projects that leadership is still insisting we avoid ESM-only packages for. The move that Sindre (and others like wooorm) made has not been well-received.

Many authors don't care if 5 dudes use their stuff, or the rest of the world, specially when taking zero monetary value out of it.

I'm one of them, as I'm a prolific open source contributor and maintainer. To argue that some high-profile authors don't get any monetary value from their public work is to be simply naive and uninformed. The two I mentioned have made careers on that work and derive the majority of their income from it.