1. About ECMAScript 6 (ES6) #

---

• 1.1. TC39 (Ecma Technical Committee 39)
• 1.2. How ECMAScript 6 was designed
  • 1.2.1. The design process after ES6
• 1.3. JavaScript versus ECMAScript
• 1.4. Upgrading to ES6
• 1.5. Goals for ES6
  • 1.5.1. Goal: Be a better language
  • 1.5.2. Goal: Improve interoperation
  • 1.5.3. Goal: Versioning
• 1.6. Categories of ES6 features
• 1.7. A brief history of ECMAScript
  • 1.7.1. The early years: ECMAScript 1–3
  • 1.7.2. ECMAScript 4 (abandoned in July 2008)
  • 1.7.3. ECMAScript Harmony

---

It took a long time to finish it, but ECMAScript 6, the next version of JavaScript, is finally a reality:

• It became a standard on 17 June 2015.
• Most of its features are already widely available (as documented in kangax’ ES6 compatibility table).
• Transpilers (such as Babel) let you compile ES6 to ES5.

The next sections explain concepts that are important in the world of ES6.

1.1 TC39 (Ecma Technical Committee 39) #

TC39 (Ecma Technical Committee 39) is the committee that evolves JavaScript. Its members are companies (among others, all major browser vendors). TC39 meets regularly, its meetings are attended by delegates that members send and by invited experts. Minutes of the meetings are available online and give you a good idea of how TC39 works.

1.2 How ECMAScript 6 was designed #

The ECMAScript 6 design process centers on proposals for features. Proposals are often triggered by suggestions from the developer community. To avoid design by committee, proposals are maintained by champions (1–2 committee delegates).

A proposal goes through the following steps before it becomes a standard:

• Sketch (informally: “strawman proposal”): A first description of the proposed feature.
• Proposal: If TC39 agrees that a feature is important, it gets promoted to official proposal status. That does not guarantee it will become a standard, but it considerably increases its chances. The deadline for ES6 proposals was May 2011. No major new proposals were considered after that.
• Implementations: Proposed features must be implemented. Ideally in two JavaScript engines. Implementations and feedback from the community shape the proposal as it evolves.
• Standard: If the proposal continues to prove itself and is accepted by TC39, it will eventually be included in an edition of the ECMAScript standard. At this point, it is a standard feature.

[Source of this section: “The Harmony Process” by David Herman.]

1.2.1 The design process after ES6 #

Starting with ECMAScript 2016 (ES7), TC39 will time-box releases. A new version of ECMAScript will be released every year, with whatever features are ready at that time. That means that from now on, ECMAScript versions will be relatively small upgrades. For more information on the new process, including finished and upcoming feature proposals, consult the GitHub repository ecma262.

1.3 JavaScript versus ECMAScript #

JavaScript is what everyone calls the language, but that name is trademarked (by Oracle, which inherited the trademark from Sun). Therefore, the official name of JavaScript is ECMAScript. That name comes from the standards organization Ecma, which manages the language standard. Since ECMAScript’s inception, the name of the organization has changed from the acronym “ECMA” to the proper name “Ecma”.

Versions of JavaScript are defined by specifications that carry the official name of the language. Hence, the first standard version of JavaScript is ECMAScript 1 which is short for “ECMAScript Language Specification, Edition 1”. ECMAScript x is often abbreviated ESx.

1.4 Upgrading to ES6 #

The stake holders on the web are:

• Implementors of JavaScript engines
• Developers of web applications
• Users

These groups have remarkably little control over each other. That’s why upgrading a web language is so challenging.

On one hand, upgrading engines is challenging, because they are confronted with all kinds of code on the web, some of which is very old. You also want engine upgrades to be automatic and unnoticeable for users. Therefore, ES6 is a superset of ES5, nothing is removed¹. ES6 upgrades the language without introducing versions or modes. It even manages to make strict mode the de-facto default (via modules), without increasing the rift between it and sloppy mode. The approach that was taken is called “One JavaScript” and explained in a separate chapter.

On the other hand, upgrading code is challenging, because your code must run on all JavaScript engines that are used by your target audience. Therefore, if you want to use ES6 in your code, you only have two choices: You can either wait until no one in your target audience uses a non-ES6 engine, anymore. That will take years; mainstream audiences were at that point w.r.t. ES5 when ES6 became a standard in June 2015. And ES5 was standardized in December 2009! Or you can compile ES6 to ES5 and use it now. More information on how to do that is given in the book “Setting up ES6”, which is free to read online.

Goals and requirements clash in the design of ES6:

• Goals are fixing JavaScript’s pitfalls and adding new features.
• Requirements are that both need to be done without breaking existing code and without changing the lightweight nature of the language.

1.5 Goals for ES6 #

The original project page for Harmony/ES6 mentions several goals. In the following subsections, I’m taking a look at some of them.

1.5.1 Goal: Be a better language #

The goal is: Be a better language for writing:

1. complex applications;
2. libraries (possibly including the DOM) shared by those applications;
3. code generators targeting the new edition.

Sub-goal (i) acknowledges that applications written in JavaScript have grown huge. A key ES6 feature fulfilling this goal is built-in modules.

Modules are also an answer to goal (ii). As an aside, the DOM is notoriously difficult to implement in JavaScript. ES6 Proxies should help here.

Several features were mainly added to make it easier to compile to JavaScript. Two examples are:

• Math.fround() – rounding Numbers to 32 bit floats
• Math.imul() – multiplying two 32 bit ints

They are both useful for, e.g., compiling C/C++ to JavaScript via Emscripten.

1.5.2 Goal: Improve interoperation #

The goal is: Improve interoperation, adopting de facto standards where possible.

Examples are:

• Classes: are based on how constructor functions are currently used.
• Modules: picked up design ideas from the CommonJS module format.
• Arrow functions: have syntax that is borrowed from CoffeeScript.
• Named function parameters: There is no built-in support for named parameters. Instead, the existing practice of naming parameters via object literals is supported via destructuring in parameter definitions.

1.5.3 Goal: Versioning #

The goal is: Keep versioning as simple and linear as possible.

As mentioned previously, ES6 avoids versioning via “One JavaScript”: In an ES6 code base, everything is ES6, there are no parts that are ES5-specific.

1.6 Categories of ES6 features #

The introduction of the ES6 specification lists all new features:

Some of [ECMAScript 6’s] major enhancements include modules, class declarations, lexical block scoping, iterators and generators, promises for asynchronous programming, destructuring patterns, and proper tail calls. The ECMAScript library of built-ins has been expanded to support additional data abstractions including maps, sets, and arrays of binary numeric values as well as additional support for Unicode supplemental characters in strings and regular expressions. The built-ins are now extensible via subclassing.

There are three major categories of features:

• Better syntax for features that already exist (e.g. via libraries). For example:
  • Classes
  • Modules
• New functionality in the standard library. For example:
  • New methods for strings and Arrays
  • Promises
  • Maps, Sets
• Completely new features. For example:
  • Generators
  • Proxies
  • WeakMaps

1.7 A brief history of ECMAScript #

This section describes what happened on the road to ECMAScript 6.

1.7.1 The early years: ECMAScript 1–3 #

• ECMAScript 1 (June 1997) was the first version of the JavaScript language standard.
• ECMAScript 2 (June 1998) contained minor changes, to keep the spec in sync with a separate ISO standard for JavaScript.
• ECMAScript 3 (December 1999) introduced many features that have become popular parts of the language, as described in the introduction of the ES6 specification: “[…] regular expressions, better string handling, new control statements, try/catch exception handling, tighter definition of errors, formatting for numeric output and other enhancements.”

1.7.2 ECMAScript 4 (abandoned in July 2008) #

Work on ES4 started after the release of ES3 in 1999. In 2003, an interim report was released after which work on ES4 paused. Subsets of the language described in the interim report were implemented by Adobe (in ActionScript) and by Microsoft (in JScript.NET).

In February 2005, Jesse James Garrett observed that a combination of techniques had become popular for implementing dynamic frontend apps in JavaScript. He called those techniques Ajax. Ajax enabled a completely new class of web apps and led to a surge of interest in JavaScript.

That may have contributed to TC39 resuming work on ES4 in fall 2005. They based ES4 on ES3, the interim ES4 report and experiences with ActionScript and JScript.NET.

There were now two groups working on future ECMAScript versions:

• ECMAScript 4 was designed by Adobe, Mozilla, Opera, and Google and was a massive upgrade. Its planned feature sets included:
  • Programming in the large (classes, interfaces, namespaces, packages, program units, optional type annotations, and optional static type checking and verification)
  • Evolutionary programming and scripting (structural types, duck typing, type definitions, and multimethods)
  • Data structure construction (parameterized types, getters and setters, and meta-level methods)
  • Control abstractions (proper tail calls, iterators, and generators)
  • Introspection (type meta-objects and stack marks)
• ECMAScript 3.1 was designed by Microsoft and Yahoo. It was planned as a subset of ES4 and an incremental upgrade of ECMAScript 3, with bug fixes and minor new features. ECMAScript 3.1 eventually became ECMAScript 5.

The two groups disagreed on the future of JavaScript and tensions between them continued to increase.

1.7.3 ECMAScript Harmony #

At the end of July 2008, there was a TC39 meeting in Oslo, whose outcome was described as follows by Brendan Eich:

It’s no secret that the JavaScript standards body, Ecma’s Technical Committee 39, has been split for over a year, with some members favoring ES4 […] and others advocating ES3.1 […]. Now, I’m happy to report, the split is over.

The agreement that was worked out at the meeting consisted of four points:

1. Develop an incremental update of ECMAScript (which became ECMAScript 5).
2. Develop a major new release, which was to be more modest than ECMAScript 4, but much larger in scope than the version after ECMAScript 3. This version was code-named Harmony, due to the nature of the meeting in which it was conceived.
3. Features from ECMAScript 4 that would be dropped: packages, namespaces, early binding.
4. Other ideas were to be developed in consensus with all of TC39.

Thus: The ES4 group agreed to make Harmony less radical than ES4, the rest of TC39 agreed to keep moving things forward.

The next versions of ECMAScript are:

• ECMAScript 5 (December 2009). This is the version of ECMAScript that most browsers support today. It brings several enhancements to the standard library and updated language semantics via a strict mode.
• ECMAScript 5.1 (June 2011). ES5 was submitted as an ISO standard. In the process, minor corrections were made. ES5.1 contains those corrections. It is the same text as ISO/IEC 16262:2011.
• ECMAScript 6 (June 2015). This version went through several name changes:
  • ECMAScript Harmony: was the initial code name for JavaScript improvements after ECMAScript 5.
  • ECMAScript.next: It became apparent that the plans for Harmony were too ambitious for a single version, so its features were split into two groups: The first group of features had highest priority and was to become the next version after ES5. The code name of that version was ECMAScript.next, to avoid prematurely comitting to a version number, which proved problematic with ES4. The second group of features had time until after ECMAScript.next.
  • ECMAScript 6: As ECMAScript.next matured, its code name was dropped and everybody started to call it ECMAScript 6.
  • ECMAScript 2015: In late 2014, TC39 decided to change the official name of ECMAScript 6 to ECMAScript 2015, in light of upcoming yearly spec releases. However, given how established the name “ECMAScript 6” already is and how late TC39 changed their minds, I expect that that’s how everybody will continue to refer to that version.
• ECMAScript 2016 was previously called ECMAScript 7. Starting with ES2016, the language standard will see smaller yearly releases.