Hacker News Reader

Comment by mattlondon | Hacker News Reader

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.

View on HN

> 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?

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.

> 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.

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.

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.

> 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.

Reply on news.ycombinator.com