Let’s stop referring to proposed JavaScript features as ES7

Now that feature list for ES2016 aka ES7 is out, and doesn’t actually include any of the features most people talk about, it’s officially time to just stop using ES7 to mean “any proposed feature that may or may not even make it”.

Let’s first define a couple things:

ES = ECMAScript = the specification that JavaScript is the de facto implementation of.

TC39 = the people who write the ECMAScript specification.

How we got here

This problem is understandable. When news originally broke that we’d finally be getting additions to the JavaScript language, people were stoked. To fully understand the process, you need to know a few things.

The first of such updates went through numerous name changes. ES.next, Harmony, ES6, then finally landed on Es2015. This was mostly due to the time it took for ES2015 to actually be finalized — 4+ years. Along the way, the goals and scope evolved, eventually realizing that instead having an arbitrary amount of time to make a new version, they should instead release a new version for each year.

Instead of ES6, ES7, ES8, etc. they would release a new version every year: ES2015, ES2016, ES2017, etc.. The theory being this would reduce pressure on TC39 since there’s always next year while also making it easier for browsers to implement these changes since they’d come on a more predictable schedule and most importantly be smaller in scope, excluding ES2015 which is rather large.

What do we call them, then?

The natural question you may ask is what do you call these features that have been proposed but not yet made it into any finalized spec? Personally, I think they should be called what they are, “proposed features” to layman but sometimes it’s helpful to distinguish where they are in the draft process.

Stages

With the new spec release cycle came a “stage” process for individual features. All changes and features go through stages 0–4, the most notable being that stage-0 features basically mean “not immediately rejected outright” (aka strawman) and stage-4 meaning the feature is final and ready for inclusion in that years spec cut. Which means it’s important to note that at any point in the stage the feature could be completely dropped. It doesn’t matter how much the community is relying on it via transpilers or polyfills, and a feature being dropped amongst controversy isn’t without precedence.

Although there will still be some transitional time, referring to a feature by stage is helpful to distinguish features which might be neat to dream about but unwise to rely on. It’s often extremely helpful as well since someone coming across your article, talk, tutorial, etc. at a later date can see which version of that feature you’re referring to. An article explaining how feature X works at stage-0 might be crucially wrong about how it works by the time it reaches stage-4.

As an example, you could say “stage-1 decorators”, which is an important clarification since the decorators spec changed rather notably after stage-0!

Conclusion

Pretty please, stop calling proposed JavaScript features ES7 :D