Its code name was Mocha.
In the Netscape Navigator 2.0 betas (September 1995), it was called LiveScript.
ECMA-262 is hosted by Ecma International. It is the primary standard.
ISO/IEC 16262 is hosted by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). This is a secondary standard.
The original name of that organization was ECMA, an acronym for European Computer Manufacturers Association. It was later changed to Ecma International (with “Ecma” being a proper name, not an acronym), because the organization’s activities had expanded beyond Europe. The initial all-caps acronym explains the spelling of ECMAScript.
The term ECMAScript refers to the language standard and language versions.
Therefore, ECMAScript 6 is a version of the language (its 6th edition).
3.3. Timeline of ECMAScript versions
This is a brief timeline of ECMAScript versions:
ECMAScript 1 (June 1997): First version of the standard.
ECMAScript 2 (June 1998): Small update, to keep ECMA-262 in sync with the ISO standard.
ECMAScript 3 (December 1999): Adds many core features – “[…] regular expressions, better string handling, new control statements [do-while, switch], try/catch exception handling, […]”
ECMAScript 4 (abandoned in July 2008): Would have been a massive upgrade (with static typing, modules, namespaces and more), but ended up being too ambitious and dividing the language’s stewards. Therefore, it was abandoned.
ECMAScript 5 (December 2009): Brought minor improvements – a few standard library features and strict mode.
ECMAScript 5.1 (June 2011): Another small update to keep Ecma and ISO standards in sync.
ECMAScript 6 (June 2015): A large update that fulfilled many of the promises of ECMAScript 4. This version is the first one whose official name – ECMAScript 2015 – is based on the year of publication.
ECMAScript 2016 (June 2016): First yearly release. The shorter release life cycle resulted in fewer new features – compared to the large ES6.
ECMAScript 2017 (June 2017). Second yearly release.
Subsequent ECMAScript versions (ES2018 etc.) are always ratified in June.
3.4. Ecma Technical Committee 39 (TC39)
Every two months, TC39 has meetings that are attended by member-appointed delegates and invited experts. The minutes of those meetings are public, in a GitHub repository.
3.5. The TC39 process
With ECMAScript 6, two issues with the release process used at that time became obvious:
If too much time passes between releases then features that are ready early, have to wait a long time until they can be released. And features that are ready late, risk being rushed to make the deadline.
Features were often designed long before they were implemented and used. Design deficiencies related to implementation and use were therefore discovered too late.
In response to these issues, TC39 instituted the new TC39 process:
ECMAScript features are designed independently and go through stages, starting at 0 (“strawman”), ending at 4 (“finished”).
Especially the later stages require prototype implementations and real-world testing, leading to feedback loops between designs and implementations.
ECMAScript versions are released once per year and include all features that have reached stage 4 prior to a release deadline.
The result: smaller, incremental releases, whose features have already been field-tested. Fig. 1 illustrates the TC39 process.
ES2016 was the first ECMAScript version that was designed according to the TC39 process.
3.5.1. Tip: think in individual features and stages, not ECMAScript versions
3.6. FAQ: TC39 process
3.6.1. How is [my favorite proposed feature] doing?
3.6.2. Is there an official list of ECMAScript features?
Yes, the TC39 repo lists finished proposals and mentions in which ECMAScript versions they were introduced.
Programmers need to know, and be continually conscious of, the differences between the versions.
You can either migrate all of an existing code base to the new version (which can be a lot of work). Or you can mix versions and refactoring becomes harder, because you can’t move code between versions without changing it.
You somehow have to specify per piece of code – be it a file or code embedded in a web page – what version it is written in. Every conceivable solution has pros and cons. For example, strict mode is a slightly cleaner version of ES5. One of the reasons why it wasn’t as popular as it should have been: it was a hassle to opt in via a directive at the beginning of a file or a function.
New versions are always completely backward compatible (but there may occasionally be minor, hardly noticeable clean-ups).
Old features aren’t removed or fixed. Instead, better versions of them are introduced. One example is declaring variables via let – which is an improved version of var.
If aspects of the language are changed, it is done so inside new syntactic constructs. That is, you opt in implicitly. For example, yield is only a keyword inside generators (which were introduced in ES6). And all code inside modules and classes (both introduced in ES6) is implicitly in strict mode.