[callumlocke]

This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.

What matters is the ongoing standardisation process. New JS features are proposed, then graduate through four stages. Once at stage four, they are "done" and guaranteed to be in the next annual ES edition write-up. Engines can confidently implement features as soon as they hit stage 4, which can happen at any time of year.

For example, async functions just missed the ES2016 boat. They reached stage 4 last July [1]. So they're officially part of ES2017 – but they've been "done" for almost a year, and landed in Chrome and Node stable quite a while ago.

[1] https://ecmascript-daily.github.io/2016/07/29/move-async-fun...

[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)

[komali2]

I don't understand who gets to use these things. We have to support back to IE11 so other than some things we've managed to find effective polyfills for, we basically just threw our hands up and code as if it's 2012.

[tracker1]

Most modern projects should probably use Babel and a bundler like Webpack for web targets. You may even want to separate legacy and modern browsers into separate targets so the 80-90% of users on evergreen browsers get a smaller download.

[komali2]

Yea, we probably should. Too many feature requests, not enough time to let us clear out the technical debt and make our stack nice and modern :(

[azernik]

I'm only two years into my current project and already am feeling this bite :-\

[tehlike]

how smaller do you think things could get?

[tracker1]

Depends, are you including ES5 shims, not to mention the corejs stuff for ES6, regenerator etc if you're using async. It all adds up. Given it's not that much in terms of size, but it's a lot in bloat for browsers that don't need it.

[peterkelly]

> I don't understand who gets to use these things

You, several years from now.

The inclusion of features in the standard is an important part of the evolution of the language. But it's just one part. More recent browsers have already implemented many of these features, and there will come a day when they're pretty much everywhere. Just be patient.

(source: I'm old and remember the era when our sites had to work with Netscape 4 due to its market share)

[pluma]

I feel you. I'm also stuck with IE11 for the time being. No CSS variables, no ES6 symbols. Babel takes the edge off it but there's still plenty we're missing out on for the time being.

Not so long ago, we had to support IE8. Before that, IE6. If you go back a little further IE5 for Mac was the biggest pain point. Before that, Netscape 4 and IE4, which were often mutually incompatible.

There will always be a legacy system many people have to support at any given time. But over time the number of people that has to worry about it will shrink along with its market share. You probably don't see many support tickets about Netscape 4 these days anymore.

Having these standards today means the next generation of legacy browsers will support them when you're stuck with them in the future. That you're not chasing the bleeding edge doesn't mean you don't benefit from these advancements, just that you'll do so with a delay, and likely far less gradually than those privileged enough only to care about the evergreens.

[alleycat]

Use CSSNext if you want css varibles now

[pluma]

Err... no.

CSS custom properties are interesting because they are dynamic. CSSNext just translates them statically, hence why it restricts definitions to `:root`. So the only thing CSSNext gives you over other "variables in CSS" preprocessors is that the syntax looks like actual CSS.

But good luck swapping out colors at runtime without recompiling the generated CSS, which is trivial with "CSS-in-JS" solutions like styled-components or glamorous.

EDIT: Also CSS variables are often advocated with `@apply` replacing preprocessor mixins. But `@apply` is pretty much dead outside faux-css preprocessors: http://www.xanthir.com/b4o00 so you probably shouldn't rely on CSSNext for this unless you understand that even if it looks like CSS what you're writing won't necessarily ever work in a browser.

[hoorayimhelping]

People using node for more than just building.

People writing internal tools.

People writing software for tech-savvy users with modern hardware.

People using babel to compile to a supported version.

[iso-8859-1]

You could use Babel.

[camus2]

> This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.

A spec is never symbolic. If a library claims it implements ES2017 then its consumer expects the library to follow the entire spec.

[pluma]

Libraries don't implement ES, JavaScript engines do.

And JavaScript engines don't implement ES editions, they implement ES features. These features now have a five stage process ending with their inclusion in the next edition of the language spec.

Most engine vendors want to be on the bleeding edge, so they start implementing features long before they are fully stable.

The reason the editions are symbolic at this point is that they are just snapshots of the collection of features that have reached stage 4 by the time they are published.

[BillinghamJ]

The per-feature specs are finalised significantly earlier than the yearly official versions. Nothing practically happens or changes.

[callumlocke]

True, but in reality such claims almost always have caveats. Like how almost no one supports ES6 imports yet.

[pluma]

To be fair, ES module semantics were not part of ES6. ES6 only defined the syntax. The appropriate semantics for implementing ES modules are currently still not 100% stable last I checked, especially because of Node which had its own module system already that needs to be unified with ES modules somehow without breaking everything or making it awkward.