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