Thankfully it was widely recognised that big bang releases like ES2015 are not the way forward - going so long between releases has many issues and it also leads to an unwillingness from many sections of the community to pick up and learn the new additions until they are supported across most popular browsers.
If you’re concerned that you’ve barely got up to speed on ES2015 and now you have an entirely new version to learn, there’s two reasons not to worry:
- ES2016 will have its full specification ratified in the summer and browser support isn’t exactly huge yet, so if you don’t want to care about it until there’s more chance of using it, that’s fine.
- If you do decide you’d like to get up to speed there’s only two features, and both are very self contained.
JS Going Forward
Future Features in the Open
If you are someone who wants to keep up with language proposals and have a sense ahead of time of the features that could potentially make it into standard, you absolutely can. Another great thing about the new process is that it’s all hosted in the open in GitHub repositories so anyone is able to take an interest.
The great news is that you can see all of this on GitHub:
By following those links you can read up more on any particular proposal and get a sense of where it’s at in the process and how likely it is to be included in the specification.
## Trying features
With the rise of transpilers like Babel it’s also now much easier to try new features out, whether those are features guaranteed to make it into a future addition, or ones that you’re interested in and would like to try. Most proposals come with a Babel plugin which you can install and then make use of the feature. You should be wary of depending on too many proposals ahead of them making it to stage 3 and beyond (once a proposal gets to stage 3, it’s likely to make it into the standard) but it’s a really nice way to try new features.
The infamous renaming of ES6 to ES2015 made no sense at the time, and lead more to confusion than anything else. However, now we have ES2016 in the works it makes much more sense to stick with the yearly naming than “ES6”, which becomes very ambigious given “ES2015” and “ES2016”. I will also be making an effort to avoid “ES7” as a term and prefer “ES next” or “ES2017 and beyond”.