> 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?
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.
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.
It's good of Ecma International to keep standing up to that. It's better for the web.
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.
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.