The TC39 process for ECMAScript features

By -


This blog post explains the so-called TC39 process, which governs how ECMAScript features are designed, starting with ECMAScript 2016 (ES7).




Related blog posts:




Who designs ECMAScript?

Answer: TC39 (Technical Committee 39).


TC39 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.


Occasionally (even in this blog post), you’ll see the term TC39 member referring to a human. Then it means: a delegate sent by a TC39 member company.


It is interesting to note that TC39 operates by consensus: Decisions require that a large majority agrees and nobody disagrees strongly enough to veto. For many members, agreements lead to real obligations (they’ll have to implement features etc.).



How is ECMAScript designed?

Problem: ECMAScript 2015 (ES6) was too large a release

The most recent release of ECMAScript, ES6, is large and was standardized almost 6 years after ES5 (December 2009 vs. June 2015). There are two main problems with so much time passing between releases:



  • Features that are ready sooner than the release have to wait until the release is finished.

  • Features that take long are under pressure to be wrapped up, because postponing them until the next release would mean a long wait. Such features may also delay a release.


Therefore, starting with ECMAScript 2016 (ES7), releases will happen more frequently and be much smaller as a consequence. There will be one release per year and it will contain all features that are finished by a yearly deadline.


Solution: the TC39 process

Each proposal for an ECMAScript feature goes through the following maturity stages, starting with stage 0. The progression from one stage to the next one must be approved by TC39.


Stage 0: strawman

What is it? A free-form way of submitting ideas for evolving ECMAScript. Submissions must come either from a TC39 member or a non-member who has registered as a TC39 contributor.


What’s required? The document must be reviewed at a TC39 meeting (source) and is then added to the page with stage 0 proposals.


Stage 1: proposal

What is it? A formal proposal for the feature.


What’s required? A so-called champion must be identified who is responsible for the proposal. Either the champion or a co-champion must be a member of TC39 (source). The problem solved by the proposal must be described in prose. The solution must be described via examples, an API and a discussion of semantics and algorithms. Lastly, potential obstacles for the proposal must be identified, such as interactions with other features and implementation challenges. Implementation-wise, polyfills and demos are needed.


What’s next? By accepting a proposal for stage 1, TC39 declares its willingness to examine, discuss and contribute to the proposal. Going forward, major changes to the proposal are expected.


Stage 2: draft

What is it? A first version of what will be in the specification. At this point, an eventual inclusion of the feature in the standard is likely.


What’s required? The proposal must now additionally have a formal description of the syntax and semantics of the feature (using the formal language of the ECMAScript specification). The description should be as complete as possible, but can contain todos and placeholders. Two experimental implementations of the feature are needed, but one of them can be in a transpiler such as Babel.


What’s next? Only incremental changes are expected from now on.


Stage 3: candidate

What is it? The proposal is mostly finished and now needs feedback from implementations and users to progress further.


What’s required? The spec text must be complete. Designated reviewers (appointed by TC39, not by the champion) and the ECMAScript spec editor must sign off on the spec text. There must be at least two spec-compliant implementations (which don’t have to be enabled by default).


What’s next? Henceforth, changes should only be made in response to critical issues raised by the implementations and their use.


Stage 4: finished

What is it? The proposal is ready to be included in the standard.


What’s required? The following things are needed before a proposal can reach this stage:



  • Test 262 acceptance tests (roughly, unit tests for the language feature, written in JavaScript).

  • Two spec-compliant shipping implementations that pass the tests.

  • Significant practical experience with the implementations.

  • The ECMAScript spec editor must sign off on the spec text.


What’s next? The proposal will be included in the ECMAScript specification as soon as possible. When the spec goes through its yearly ratification as a standard, the proposal is ratified as part of it.



Don’t call them ECMAScript 20xx features

As you can see, you can only be sure that a feature will be included in the standard once its proposal has reached stage 4. Then its inclusion in the next ECMAScript release is probable, but not 100% sure, either (it may take longer). Therefore, you can’t call proposals (e.g.) “ES7 features” or “ES2016 features”, anymore. My two favorite ways of writing headings for articles and blog posts are therefore:



  • “ECMAScript proposal: the foo feature”. The stage of the proposal is mentioned at the beginning of the article.

  • “ES.stage2: the foo feature”


If a proposal is at stage 4, I’d be OK with calling it an ES20xx feature, but it’s safest to wait until the spec editor confirms what release it will be included in. Object.observe is an example of an ECMAScript proposal that had progressed until stage 2, but was ultimately withdrawn.



Further reading

The following were important sources of this blog post:



Other things to read:




Comments

Post a Comment

Popular posts from this blog

Steve Lopez and the Importance of Newspapers

By -
Image
It has been one year since I cancelled my subscriptions to The New York Times and the Los Angeles Times . In that time, I continued to read both publications online. My assessment of this experiment is that reading newspapers and journalism online is vastly inferior to the hard copy thrown on my porch each morning. So I restarted my subscription to the Los Angeles Times and I have made it a point to buy The New York Times as often as I pass one of those coin boxes or my local news stand. The catalyst for this re-evaluation resulted from catching the film, The Soloist on cable last week. I liked the movie, although the scenes I found most interesting were the ones that showed columnist Steve Lopez at work. I realized the book was sitting in my “to-read” stack, so I pulled it and began reading. The book, as I expected, is better than the film. Lopez clearly addresses the revolution occurring in journalism, and worries about his future with the paper even as he researches and writes...
Keep reading

Ideas for fixing unconnected computing

By -
I traveled quite a bit recently and got exposed to a negative aspect of current technology: Things work well if you have a solid internet connection with no traffic limits and are plugged into a power outlet. Otherwise, things do not work well at all. This blog post describes the problems that arise and suggests solutions. Managing data traffic Cell phones are quite good at conserving traffic, laptops much less so. This becomes a problem when your laptop has a mobile connection (e.g., via tethering or in a hotel with data caps). I once accidentally started iTunes in such a situation and immediately used up my daily allowance of traffic. Similarly, mobile email is frugal with traffic (only the current folder is updated, attachments are only downloaded on demand, etc.), desktop email is usually not. How can this be handled better? I’d like to see three traffic modes for all operating systems: “full”, “restricted”, “minimal”: In full traffic mode , all data transfers are allowed and happe...
Keep reading

Omar to kill me

By -
Image
  The sentence “ Omar m’a tuer ” is unintelligible French, as if it had been written by an illiterate person. At first sight, Mme Ghislaine Marchal —the author of those words in blood—seems to be saying that she had been killed by Omar in her villa at Mougins (Alpes-Maritimes). But why would that dying French lady have used such poor grammar? On that flimsy evidence, in 1991, the Moroccan gardener Omar Raddad was condemned and jailed. But he persisted non-stop upon his innocence. In 1998, he was liberated, and now lives in Morocco. A recent analysis of DNA specimens from the scene of the crime provides new facts. Four males, none of whom was Omar Raddad, have left traces of their presence. Will the real murderer be identified at last?
Keep reading