ECMAScript standardization process
Living in the frontend ecosystem it's very common to listen to people saying how fast the community is evolving. This is true and it's one of the reasons why we are more and more enable to build and ship new and amazing things.
This is even truer when we think about the frameworks we have and how fast new versions are being released, and many even include Javascript(JS) itself in this comparison. But… was it always like this?
As you can see in the image above, there was a huge gap between 1999 and 2009, and during this time, Javascript was kind of considered ̶a̶ ̶m̶e̶s̶s̶ not so awesome as we know it nowadays.
After ES3 was released, they had big plans for the language, but they were too ambitious. The result is that they ended up abandoning ES4 in 2008. A year later they released ES5 with some minor improvements (a few standard library features and strict mode).
When ES6 was released, in 2015 (six years after ES5), many of the features they wanted for ES4 came, and they made this version the first one officially named ECMAScript(ES) followed by the year of the release. After that, they decided to release one ES version per year (this is how we ended up with ES.Next/ES6+ terms).
How are the releases managed?
There's a committee that evaluates new JS proposals: the Technical Committee 39(TC39). These proposals, that can be suggested by anyone, pass through different stages when being evaluated by the TC39. These stages follow the following order:
Stage 0
A sketch is the starting point. Someone has an idea and decides to write it up.
Stage 0 proposals are either
- planned to be presented to the committee by a TC39 champion, or
- have been presented to the committee and not rejected definitively, but have not yet achieved any of the criteria to get into stage 1.
This means that even if they seem good, it's way too soon to start using it.
Stage 1
The idea is presented to the TC39, and they start debating it (make comments).
Stage 1 proposals represent problems that the committee is interested in spending time exploring solutions to.
This means that it's still too soon to start using it, and also to be hopeful, but hey… it's better than 0!
Stage 2
When a proposal goes to Stage 2, the TC39 discuss if the feature should really be in the language. They expect that all major semantics, syntax, and API are covered, but there might still have TODO's, placeholders and editorial issues.
Stage 3
When a proposal gets to this stage, it indicates that the solution is complete and no further work is possible without implementation experience, significant usage and external feedback.
Normally Chrome already implements it, but it's not guaranteed it will become official. Polyfill implementations are also provided as the final form proposal takes shape.
Stage 4
Yayy! The proposal was accepted and will be included in the next release! It's totally safe for you to start using it!
As you can imagine, this process is not fast and sometimes a proposal takes around 10 years to go from stage 0 to 4 and finally be included in an ES20XX release.
Conclusion
Javascript is evolving really fast and, behind the scenes, there's a technical committee that evaluates new features proposed for the language.
These proposals can be made by anyone, and they have to pass through 4 stages to become standardized in the language.
This process takes time because the TC39 needs to ensure that every new version keeps backward compatibility, as not all users have the capability to upgrade their operating system or their browsers. Have you ever thought why would someone use var instead of let or const since ES6? There's no advantage in using var nowadays, but they don't remove it in order to provide backward compatibility for old websites.
Even if a browser is already supporting a proposal that hasn't reached stage 4 yet, it doesn't mean it will become part of javascript (there is a risk! Low, but there is — and this is one of the reasons why Internet Explorer has always been a pain, as you can read more about it here).
Many developers are actually doing it via tools like babel, that allows the inclusion of features that are even still on stage-0. I personally think it really depends on the use case, but if you're using something that hasn't become a standard in the language yet, I'd recommend you to keep following the status of the proposal on this page or also this one. Since every year a new version of the language is released with all proposals that went to stage 4, maybe you will find your preferred ones are there!
Useful links:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Language_Resources
