JS.next: A Manager's Guide

Chapter 2. ES6 Goals

Why is so much happening now? JavaScript’s current development path reflects years of prior work.

History in the Making

After years of hard work, deep thought, and discussion, JavaScript was about to change in July 2008. Many brilliant minds spent years debating, and at times fighting over, what the next steps for JavaScript should be. They spent years watching the Web organically grow and evolve. That growth meant different things for many companies and individuals. These people and companies had unique and distinct opportunities, if they could only make a few changes of their own to JavaScript. These biases made life difficult for the TC39, the committee in charge of steering the ECMAScript specification. None of the people tasked with guiding ECMAScript (and, by proxy, JavaScript) could have predicted the challenges they would face as they attempted to accomplish their task.

As in many debates, all sides argued their honest opinions about what needed to be changed in order to further the progress of the language. Prior to July of 2008, many of these debates became heated, and very few saw much progress, if any. Due to these conflicts, the small group that initially endeavoured to fight for JavaScript inevitably broke down. Brendan Eich, the creator of JavaScript, compared the history of the ECMAScript standardization committee to Peter Jackson’s Fellowship of the Ring, in the sense that a once strong group of friends ultimately divided into smaller groups, taking separate journeys. (See Douglas Crockford’s “The State and Future of ECMAScript” and Brendan Eich’s Lord of the Rings analogy.)

These separations had all but stagnated the progress of the language for years. In the years prior to July 2008, progress in the browser (and specifically JavaScript) had come to a halt. (See http://bit.ly/10joIZO and http://bit.ly/18NhG3p.) Something had to give if this would ever change. Not everyone could get what they wanted if JavaScript were to move forward.

The Meeting

Opera hosted the TC39’s monthly meeting in Oslo, Norway’s capital. The parties reached a compromise, deciding that a small subset of features, from the much larger feature set that had been discussed, would be released under the name ECMAScript 3.1. Later, the name would be changed from ES3.1 to ES5 to account for the progress that was made.

The final ES5 specification was approved in June of 2011. This marked a huge step forward for browser vendors. Progress and standards prevailed, and JavaScript was again moving forward with new features. This was all very cool.

Harmony

What about all the other features that no one could agree upon? What happened to the features that weren’t included in the ES3.1 subset?

Most of the ideas that people had for ECMAScript fell into this bucket. In August 2008, Eich addressed the ES standards body (TC39) and let them know that all remaining features would be grouped into a collection labeled “Harmony,” a tribute to all the committee members that came together to help move the language forward again. In his email, Eich outlined a list of goals for the Harmony features. A few additional goals have been standardized since then, and they can be found on the ES Harmony wiki. The goals include:

1. Provide a better language for writing

   1. complex applications;
   2. libraries;
   3. code generators targeting the new edition.
2. Switch to a testable specification.
3. Improve interoperation, adopting de facto standards where possible.
4. Keep versioning as simple and linear as possible.
5. Support a statically verifiable, object-capability secure subset.

These goals still guide TC39 today.

Complex Applications

JavaScript began as a simple language for manipulating objects, though it contained features allowing much more. It now supports full-blown server platforms and has transformed the browser into the app container of choice. The landscape has completely changed, and continues to change every few years. JavaScript needs features that allow for less coding while producing more functionality.

Libraries

Any given page on the Internet may have dozens of JavaScript dependency files. As a JavaScript project becomes larger, the task of library and dependency management increases in difficulty. Harmony has a handful of features that will provide a better experience for library builders and app developers alike.

Adopt De Facto Standards

JavaScript is only one of the programming languages involved in building modern web applications. Many of today’s best developers have other languages they love in addition to JavaScript. The silver lining in being late to the web standards game is that you get to see what everyone else is doing, and you can aggressively reject the bad and assimilate the good. The ECMAScript specification is adopting many of the most popular features from some of today’s best languages, including Python, Ruby, and CoffeeScript. This will make JavaScript appear to be more familiar and friendly to developers that have a grasp on those other languages.

ES6: Subsetting Harmony

Immediately after ES5 was formally released, the TC39 began discussing and planning the next update to the ECMAScript specification. Many committee members already had favorite features in mind. Because of that, many features were quickly sorted to the front of the line.

A handful of these features have been part of Mozilla’s Firefox for the past four to five years (yes, they predate the ES5 specification approval). I found several instances of ES6 features existing in production browsers, including a six-year-old code commit to the Firefox source code by Brendan Eich himself, in which he implemented Destructuring. This means that the browser vendors implemented many features that had yet to be officially approved by the standards committee. That may sound bad; it is extremely likely that this accelerated the process of approving features for the ES6 specification. Because the features were already in production browsers, it was easier for the committee to see how they would affect the language.

Less than two years after the ES5 specification was officially approved, the TC39 has already finalized their list of proposed features for ES6. With the list finalized, no new features will be added to the ES6 specification. At this point, the committee is drilling in on each of the new features, making sure that all the JavaScript nuts and bolts have been tightened to ensure that these new features aren’t going to break the Web. By the time they are done, the ES6 specification will be officially approved.

The TC39 has currently targeted December 2013 as the date for the final draft of the ES6 specification. They will then give their customers 12 months to implement the specification and provide feedback. Several major browser vendors have already begun implementing ES6 features for use in production websites. The rollout of these features will be swift, happening quickly around the end of 2013 and the beginning of 2014. If all goes as planned, the committee will officially and finally approve the ES6 specification by December 2014. If they can maintain that pace and meet those targets, they will have successfully pushed two major updates to the specification in fewer than four years.

With progress happening at such a rapid pace, the Web is now prepared to see more growth than ever.