Having been working mainly with various front-end technologies and tools over the past few years, I noticed that many developers are mentioning the acronyms ES5, ES6, ES8, etc. When I’ve asked some of them if they knew what those things were, they couldn’t really answer me. Thus, I decided to share my knowledge about JavaScript standardization in this article.
Before going any further, I want you, the reader, to question yourself – Do you know what those ES things which frontend developers are often referring to, stand for? Do you know the difference between ECMAScript and JavaScript? Do you know who is responsible for giving life to the new JavaScript features, which you are using in your everyday work?
As I mentioned before, everyone can propose a new functionality to be incorporated into the standard and all of those ideas are going into Stage 0 – “Strawperson”. This is the initial state of the feature proposal and there aren’t any specific requirements here, just coming up with a creative idea.
If that idea is favored by someone from the committee it goes to the next stage – Stage 1, Proposal. This is the first formal stage of a new feature development. The person who recommends the addition should provide an explanation of his motivation for introducing the extension. The member of committee who liked the idea becomes a “champion”, who is responsible for outlining the problem, discussed at the regular meetings and urging TC39 to review it. At this stage major changes are allowed.
If the feature has the committee’s approval, it goes to the next level – the list with Stage 2 “Draft” proposals. At that point the author should precisely describe the syntax and semantics, using formal spec language, as well as provide experimental implementation. Only incremental changes are allowed from that point onwards.
The next stage is called – Stage 3 “Candidate”. Reaching that phase means that the addition is almost done. Its semantics, syntax and API are completely described, and only modifications motivated by critical problems could be applied. Also, reaching this state means that all committee members have signed off that the feature should be included in a future standard version.
The final Stage 4 “Finished” means that the addition has been significantly tested and integrated in most popular browsers. All the proposals at Stage 4 are included in the next standard candidate draft at the beginning of February each year.
The whole process of giving life to one new feature could last from a couple of months to a few years. So, the main reason for adopting this development lifecycle is not to block ready-to-be-released features because of discussions on unfinished functionalities.
A brief history of JavaScript
So, in order to answer all those questions, we should go back 20 years in time – to the early years of the web when most people thought that the Internet was just a hackerish thing. In the spring of 1995, a team at NetScape wanted to develop a language, which could run in the browser and make their work on building web applications easier. The legend says that one of their developers, Brendan Eich, created the first version of JavaScript in only 10 days. Its original name was Mocha, then it was renamed to LiveScript but after many discussions the developers at NetScape agreed over the name – JavaScript, as at that time Java was extremely popular and NetScape wanted something similar to quickly popularize it.The early years
In the following years, NetScape took JavaScript to the ECMA standards organization to standardize it, so the other vendors could implement JavaScript into their browsers. What is more, TC39 (Technical committee 39) was created to be in charge of the evolution of the standard as every new feature was coming from it. Those events led to the initial release of JavaScript under the name – ECMA-262 Ed. 1 or ECMAScript in June 1997. In the next 3 years, there were 2 releases which added significantly useful features to the standard. Here is the right moment to say that the actual versions aren’t called ES1, ES2, ES3, etc. Their actual names are ECMAScript XXXX, where XXXX is the year of the release but developers shorten it to ES combined with the version number of the release for convenience purposes.
The abandoned release
Initially, everything with JavaScript was going well and big plans and promises for improving the language were made. The beginning of the millennium saw the official start of the work on ECMAScript 4. That was a key moment in the JavaScript history, since the release was extremely anticipated and some of the members of TC39 even called it “JavaScript 2”. In 2003, the committee issued an interim report, containing only some of the functionalities earmarked for ES4However, shortly afterwards the release was terminated. Around this time, a new technique for creating dynamic client-side web applications, using JavaScript, emerged and Jesse James Garrett, a well-known UX designer, invented the new approach called AJAX in his white paper in February 2005. This publication hyped the committee to renew the work process on the new standard version, but with no success. When TC39 got together again they were divided into two camps – the one was the “ECMAScript 4” camp seeking a huge upgrade, and on the other side was the “ECMAScript 3.1” camp, who were only interested in upgrading a small subset of ES4. After numerous controversial discussions, in July 2008, at a meeting in Oslo TC39 made a decision. ECMAScript 4 was abandoned, and a polished version of ECMAScript 3.1 was going to be released as ECMAScript 5. Finally, in December 2009, the new release was officially announced.ECMAScript 2015
Moreover, TC39 decided that their entire development process should be revamped and started working on the planned improvements. They agreed on three major things:- Small improvements, no big promises
- Strict release lifecycle
- Community-driven improvements
Proposals Lifecycle
After the long years of discussions and considerations, the committee finally came to an agreement over a strict proposal lifecycle and fixed a yearly standard version as they recognized the need of upgraded versions in a timely manner. Moreover, the proposals became community-driven, instead of corporate-driven. But let’s dive deeper into the whole development process of one new ECMAScript functionalities. It consists of one informal and four formal development “stages”:
As I mentioned before, everyone can propose a new functionality to be incorporated into the standard and all of those ideas are going into Stage 0 – “Strawperson”. This is the initial state of the feature proposal and there aren’t any specific requirements here, just coming up with a creative idea.
If that idea is favored by someone from the committee it goes to the next stage – Stage 1, Proposal. This is the first formal stage of a new feature development. The person who recommends the addition should provide an explanation of his motivation for introducing the extension. The member of committee who liked the idea becomes a “champion”, who is responsible for outlining the problem, discussed at the regular meetings and urging TC39 to review it. At this stage major changes are allowed.
If the feature has the committee’s approval, it goes to the next level – the list with Stage 2 “Draft” proposals. At that point the author should precisely describe the syntax and semantics, using formal spec language, as well as provide experimental implementation. Only incremental changes are allowed from that point onwards.
The next stage is called – Stage 3 “Candidate”. Reaching that phase means that the addition is almost done. Its semantics, syntax and API are completely described, and only modifications motivated by critical problems could be applied. Also, reaching this state means that all committee members have signed off that the feature should be included in a future standard version.
The final Stage 4 “Finished” means that the addition has been significantly tested and integrated in most popular browsers. All the proposals at Stage 4 are included in the next standard candidate draft at the beginning of February each year.
The whole process of giving life to one new feature could last from a couple of months to a few years. So, the main reason for adopting this development lifecycle is not to block ready-to-be-released features because of discussions on unfinished functionalities.
ECMAScript Release Lifecycle
Furthermore, the committee takes a specific approach when it comes to delivering the new standards succeeding ECMAScript 2015. Here is an approximate timeline. The new release Candidate Draft is introduced at the beginning of February. The next two months are a period for testing all the stage 4 proposals. At TC39’s Meeting in March all stage 4 proposals are incorporated and approved. The new specifications version is branched from master and only editorial changes are allowed. In the next three months ECMA reviews the proposal of the new version and if everything goes well, the official yearly release standard comes to life in July.
You might be wondering why you should know all those facts. What I wanted to show you with my article, is the big effort that someone else does in order to make our lives as programmers easier and the end user’s experience more delightful.
So, here is my advice for all programmers – go for the newest version, it will minimize your efforts and make your life easier.
And if you are a business owner and you are wondering why your team insists on using new technologies and constantly refactoring the code, then give them a chance, new technologies don’t bite.
Choosing the right technology stack is at the foundation of your successful business and many times the latest technologies are the answer. Learn how we can help you leverage their power!