[MCArth]

I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads

It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem

I'm not sure what the solution is, but I no longer use any packages which export only an es module.

[mattlondon]

I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things.

It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.

[whostolemyhat]

> why should ECMAscript care about what node does?

Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

[lelanthran]

> Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification.

Normal exceptions for languages that have a spec based on a reference implementation.

[ByteJockey]

That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation.

V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno.

Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8.

The Ecma International is basically naval-gazing at this point. They don't control JS, google does. Just see what happened when they added TCO to the spec and google didn't implement it.

[WorldMaker]

JS isn't supposed to have only one relevant implementation, though, and still has two active implementations (SpiderMonkey). (And up until recently usually had at least three active. RIP Chakra.) That's absolutely a bug in the ecosystem that the Chromium hegemony has bullied its way into near monopsony.

It's good of Ecma International to keep standing up to that. It's better for the web.

[ByteJockey]

> JS isn't supposed to have only one relevant implementation

I mean, alright, but the way things are supposed to be doesn't have any bearing on the way things actually are. And if you plan based on how things are supposed to be instead of how they are, you're going to experience a lot of pain.

> It's good of Ecma International to keep standing up to that.

In what way are they standing up to it? By keeping things in/out of the spec? My claim here is that the spec doesn't matter. If chrome implements something, people will use it, even if it isn't in the spec, and just let things break in other browsers. If chrome doesn't implement it, people won't use it, even if it is in the spec. You don't see poly-fills for chrome.

[mattlondon]

The same could be said about individual browsers. With web standards there is precedent for doing the "right" thing rather than just going along with whatever one product has already implemented and calling it a standard.

E.g. there were recent posts here on HN about WebSQL (already implemented in Chrome so many hundreds of millions of users) being replaced by a design agreed upon by all interested parties rather than just what Google wanted for Chrome and Gmail. Indexdb may not be what everyone wanted of course, but that is beside the point.

There is a place for experimentation and trying stuff out, but just shipping something first shouldn't mean you get to dictate future standards or be guaranteed backwards compatibility or a zero-effort upgrade path. Standards should learn from and build upon earlier implementations and mistakes. They should not be slaves to what has gone before.

[an1sotropy]

You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here:

Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something?

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[MCArth]

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

[an1sotropy]

ok, that makes sense (and sorry for making you answer twice). But I think sometimes a clean break is a necessary part of progress.

[WorldMaker]

I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too).

It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around.

It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in.