In our recent post about the key features in ES2017, I was reminded just how much the standards process has changed in the past 15 years. As someone who tried to get involved early to improve standards, the process was broken and I was quickly discouraged. However, much has changed since the early days of the web.

Back in the early 2000s, standards bodies attempted to codify features already implemented, and attempts to extend the web were often overly complex. The process typically occurred behind closed doors, usually with a few large companies attempting to push their technology agenda, with little opportunity for the public to participate in the process other than perhaps a mailing list. The collaborative tools we rely on today simply did not exist, and most browser implementations were not based on open source software. Simply put, it was difficult to make progress in that environment.

Here we’ll look at the non-technical side of the standards process, and how modern web standards are evolving in a more open and collaborative manner, leading to a better web platform.

Defining all the letters and numbers

ECMA. A standards body, most famously known in the web community as the home of JavaScript (aka ECMAScript).

ECMAScript is a standard script language, developed with the cooperation of Netscape and Microsoft and mainly derived from Netscape’s JavaScript, the widely-used scripting language that is used in Web pages to affect how they look or behave for the user.

ECMA-262. The ECMA standard number for ECMAScript.

TC39. Technical Committee 39 is the group responsible for the standardization of the general purpose, cross platform, vendor-neutral programming language ECMAScript. This includes the language syntax, semantics, and libraries and complementary technologies that support the language.

WHATWG. The Web Hypertext Application Technology Working Group (WHATWG) is a community of people interested in evolving HTML and related technologies. The WHATWG was founded by individuals from Apple, the Mozilla Foundation and Opera Software in 2004.

W3C. Standards body known for many recommendations including HTML, CSS, SVG, DOM, and ARIA/WCAG.

The TC39 Today

The most notable changes in recent years to the TC39’s approach to its standards process are:

Increased Community Engagement

The formation of the WHATWG is a key turning point in standards bodies becoming more open and transparent in their process, which is codified in part through the Extensible Web Manifesto. Given the greater interest in JavaScript, the TC39 now engages with the wider development community in an open and collaborative manner.

Annual Releases

After the substantial changes in ES6, an important decision was made to make smaller, incremental annual releases going forward to reduce the scope of any one version of ES going forward. After a huge backlog of features landing in ES6, only a few small features were added for ES2016. ES2017 has a larger but still very manageable number of new features.

The TC39 committee meets several times per year in person to talk through various proposals. Because of its size, breakout sessions are common to allow for more involved discussions around some of the proposals.

So how does a feature become part of the next version of the language?

Ideas are submitted as proposals and at each stage of the proposal and then feedback is given and incorporated into the proposal to refine its implementation. Here are the stages a feature moves through to become a standard.

Stage 0: Strawman Proposal

Ideas are casually discussed and possibly submitted to Github for further discussion and consideration.

Stage 1: Proposal

This is a more formal proposal with an official champion and either a polyfill or transpiler implementation to demonstrate how the feature would work. Most proposals never get past Stage 1, and that’s a good thing, as this prevents features from being added to the language that are not ideal for the goals of the language.

Stage 2: Draft

The Proposal becomes a formalized document that is consistent with how the ES specification is authored, with at least one experimental implementation. The most famous feature to be withdrawn under the new TC39 process is Object.observe, which was removed during stage 2.

Stage 3: Candidate

At this point, the proposal is awaiting final feedback, and ideally at least two specification-compliant implementations exist. Most Stage 3 features are expected to end up in the language.

Stage 4: Finished

Stage 4 concludes the process and the feature will be incorporated into the next annual version of the language specification (ES.Next). Proposals that have reached the Finished state by February 1st are added to a candidate draft, which is finished and approved in July.

At that point, JavaScript engine implementers, transpiler authors, and framework authors work to leverage the new features as quickly as possible! The kangax compatibility table tracks the current status of support for new language features, and six speed helps track the implementation performance of new features.

Summary

With this improved, open, and collaborative approach to defining standards, we are seeing solid additions to the language at a rapid pace that still affords time for reasonable consideration of their usage. This is allowing the platform on which we build web applications to steadily improve more efficiently than in the past!