4 ms·

This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point. What matters is the ongoing standardisation pr

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-functions-to-stage-4-per-july-2016-tc39-meeting-tc39-proposals-e8c0354 https://ecmascript-daily.github.io/2016/07/29/move-async-fun...

k__ 9y ago
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 9y ago
  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.
  - hzoo 9y ago
    The purpose of https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env is that it handles all this automatically (not run when it's supported natively)
  - callumlocke 9y ago
    > 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 9y ago
      I agree. My point was in contrast to the attitude that once something is in babel that's all that matters.
camus2 9y ago
> 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.
- BillinghamJ 9y ago
  The per-feature specs are finalised significantly earlier than the yearly official versions. Nothing practically happens or changes.
- callumlocke 9y ago
  True, but in reality such claims almost always have caveats. Like how almost no one supports ES6 imports yet.
  - pluma 9y ago
    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.
  - deleted 9y ago
    [deleted]
- pluma 9y ago
  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.
komali2 9y ago
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.
- iso-8859-1 9y ago
  You could use Babel.
- hoorayimhelping 9y ago
  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.
- tracker1 9y ago
  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 9y ago
    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 9y ago
      I'm only two years into my current project and already am feeling this bite :-\
  - tehlike 9y ago
    how smaller do you think things could get?
    - 9y ago

k__ 9y ago

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 9y ago
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.
- hzoo 9y ago
  The purpose of https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env is that it handles all this automatically (not run when it's supported natively)
- callumlocke 9y ago
  > 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 9y ago
    I agree. My point was in contrast to the attitude that once something is in babel that's all that matters.

camus2 9y ago

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

BillinghamJ 9y ago
The per-feature specs are finalised significantly earlier than the yearly official versions. Nothing practically happens or changes.
callumlocke 9y ago
True, but in reality such claims almost always have caveats. Like how almost no one supports ES6 imports yet.
- pluma 9y ago
  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.
- deleted 9y ago
  [deleted]
pluma 9y ago
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.

komali2 9y ago

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.

iso-8859-1 9y ago
You could use Babel.
hoorayimhelping 9y ago
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.
tracker1 9y ago
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 9y ago
  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 9y ago
    I'm only two years into my current project and already am feeling this bite :-\
- tehlike 9y ago
  how smaller do you think things could get?
  - 9y ago