[k__]

As far as I understood it:

ECMAScript is more a thing for backwards compatibly.

Things get proposed and HAVE to be implemented in runtimes before they get into ECMAScript.

They want to know if things can be implemented nicely before they standardize them.

This is more a game between ECMA and Browser vendors, JS compilers (like Babel) and vendors of other JS runtimes like Node.js.

If you are an enduser, i.e. a user of Babel, it's more a question of the support you get from the Babel devs.

They say JSX is on? No matter what ECMA says, as long as Babel gets this compiled into ECMAScript conforming JS.

[rictic]

I think it does matter to end user developers though. Once something is in the standard, you can rely on it. It won't change in a backwards-incompatible way.

That means that you're not imposing an unusual configuration on downstream users, and depending on the environments you support, at some point you won't even need to run Babel at all.

With IE11 approaching end of life, and more and more sites dropping support for it, we're rapidly approaching a time when we can assume the vast majority of users are on a modern, evergreen browser. And the last version of node that didn't have full ES6 support just went out of long term support.

[callumlocke]

> Once something is in the standard, you can rely on it. It won't change in a backwards-incompatible way.

That's what stage 4 means. Completely finalised. Appearing in the next 'edition' document is just a formality. Once it's stage 4, it's effectively in the standard. If you restrict yourself to stage 4 features, you have all the same guarantees you mentioned. If you restrict yourself to the last published edition, you'd have missed out on async functions until almost a year after they were completely finalised, for example.

> the last version of node that didn't have full ES6 support

No version of Node supports ES6 imports yet, which is a huge part of ES6, and it won't be supported for at least another year. This emphasises the point that following ES editions is pointless.

All that matters is what combination of individual features is supported by your engine. Thinking in editions has pretty much no benefit.

[rictic]

I agree. My point was in contrast to the attitude that once something is in babel that's all that matters.

[hzoo]

The purpose of https://github.com/babel/babel-preset-env is that it handles all this automatically (not run when it's supported natively)