A Year (plus a little) on TC39
Dispatches from the future of JavaScript
Author’s note: In this post while explaining where a certain programming language comes from, I use the terms “JavaScript” and “ECMAScript®” interchangeably. There is a difference, but it’s pedantic and not worth getting into today.
In August 2017, fellow PayPal engineering JavaScripter Kent C. Dodds contacted me with an opportunity: PayPal is an “Ordinary Member” of Ecma International, he told me, and that meant that PayPal could send any delegate(s) they wish to attend meetings of TC39, the committee that writes the spec for JavaScript. He wanted to know if I’d be interested in representing PayPal, Braintree, and Venmo in the committee. I had never thought about where JavaScript came from, but suddenly I was eager to find out. So I said “yes” without giving the commitment much thought, then started researching what, exactly, I had volunteered for.
Wait — someone does that?
All the ES5 and ES6 features I’d been so excited about a few years ago had to weave their way through the TC39 committee process. Changes to the spec aren’t added at random by a browser engineer anxious to implement a feature in their next release, but go through an actual process with actual experts who know what they’re talking about.
The dedicated folks who make up TC39 come from all manner of professional backgrounds. We have developers at every level of interaction with JavaScript: people who work on JavaScript engines, framework authors, web developers, and more. Having such a mixture of experience allows us to put care and thought into every decision we make, and understand how it will impact anyone who deals with JavaScript.
Don’t break the web
The number one guiding principle, which the committee is unbending on, is “Don’t Break the Web”. Frequently, JavaScript community members don’t see just how broadly that applies to every single decision we make.
We have to be unbending on that principle because, unlike most languages, JavaScript needs to be backward compatible — forever. When contemplating “breaking” changes, we can’t just call it a major version bump and move on — once something’s in, it’s in for good. (Just think of what would happen to all those archived Geocities sites if we removed String.prototype.fontcolor(color)). (Please do not ever, ever use String.prototype.fontcolor(color)) We pay close attention to common usage in the past and take note of any frameworks and conventions that were used regularly at some point, even if they aren’t common now. Naturally, we’re also on a mission to future-proof to the best of our ability. We don’t want to make it harder for ourselves to make additions or changes in the future. (The word “footgun” is thrown about a lot during plenary.)
We also have to look outside of the ECMAScript® spec to make sure our work plays nice with anything JavaScript regularly interacts with. Several delegates are directly or indirectly involved with other related standards bodies, like W3C’s TAG, WHATWG, IETF, and others. By collaborating with other standards groups, we make sure that conflicting ideas can be worked out, and that work isn’t unnecessarily duplicated.
The naming of things¹
Whether in collaboration with other standards bodies or independently, TC39 has to put an absurd amount of thought, research, and planning into the naming of things. Naming is famously regarded as the hardest thing in programming, but it’s triply so when working in a language like JavaScript. In addition to the general challenges that make naming hard, the struggle is compounded by “it can never be changed or deleted” as well as “it can’t be so obvious that people are already using it in a way that would cause a conflict”. (See also, that time a Stage 3 proposal broke flickr).
An average meeting
When we get together in person for three day bimonthly plenaries, the agenda follows a predictable format even if the content varies dramatically. Agenda items come from the editors of our various publications, members of subcommittees, updates from other standards bodies, security issues, and of course, proposal updates. (I’ll go into the proposal process, which drives the vast majority of feature additions and changes to JavaScript, in a future post).
Early in the first day, editors and subcommittee members report on their activities between meetings. The editors of the spec² take a moment to update everyone on any changes and their relevance to ongoing work. Additional editor’s reports include those from the internationalization API and JSON specs, as well as Test262, the canonical ECMAScript® test suite. We also have the Code of Conduct committee and several outreach subcommittees that offer updates of their activities between meetings.
TC39’s approach to its work is unique in the standards world; decisions are made by consensus, as opposed to voting like other standards bodies. The primary reason for this difference is the near-immediate and unavoidable burden that stakeholders take on when changes and additions are made to the language. The consequence is that new features mean more work for implementors, who need a way to put a stop (whether temporarily or permanently) to changes that they cannot execute on.
Because we need consensus, conversations can break out of their time boxes easily. This can be frustrating from time to time, but it allows for concerns to be heard from all angles. JavaScript is run in such a wide variety of environments — of course browsers, but also native applications, IoT devices and in space — that we discover unexpected constraints in the course of a discussion.
During meetings, a small number of praiseworthy scribes take notes almost detailed enough to be considered transcripts. They also make a note of final conclusions of the topic at hand, whatever it may be. About two weeks after everyone goes home, notes are published on GitHub for anyone to read. If you’ve ever seen changes to JavaScript and thought “what on earth were they thinking?”, the notes can be especially illuminating. The story behind every conclusion is buried somewhere in that repo, just waiting to be read.
The real work starts
The bulk of the work TC39 does happens between meetings on GitHub and IRC. The lessons learned and conclusions reached in the previous meeting are applied to the code, prose, and tests found in proposal repos. Over in the world of browsers and JavaScript engines, engineers start to implement features that are ready for real-world testing. And of course, bikeshedding³ abounds in the GitHub issues.
We don’t fill our time with purely technical work, though. We’re currently developing several nascent outreach groups for specific constituents like educators and framework authors. Our goal is to offer more lines of communication than just GitHub issues and IRC, so we can reach the community where they are and solicit feedback. There’s also a beta website in the works, with information on current proposals, links to meeting notes, and explanations of what we do and how.
Back at Braintree
It’s my firm belief that no one needs to be an expert in every aspect of JavaScript. I work with TC39 as a Braintree software engineer, not an author of a browser or engine. Participating in the standards process has really driven home how to communicate the most important priorities in development for the web. Those priorities take many shapes, but “Don’t break the web” should be a principle not just for this committee, but for anyone who works on SDKs, authors frameworks, or publishes packages of any kind. When it comes to building products people depend on, as my manager recently advised: “Move slow and maintain things.”
This post is just an introduction to what TC39 does and how we work together to move JavaScript forward. As co-chair in 2019, I’m looking forward to providing more insight into the committee and making sure new voices are heard. If you’d like me to cover a specific facet of TC39 in another post, drop me a line at aki.braun@getbraintree.com.
- Yes, this song is stuck in my head. It’s a good title.
- For ES2019, editor-in-chief Brian Terlson with editors Jordan Harband & Bradley Farias
- Bikeshedding, also known as Parkinson’s law of triviality, is the idea that organizations give disproportionate weight to trivial issues. The fictional example Parkinson gave was a committee analyzing plans for a nuclear power plant, but spending the majority of its time discussing details such as the color and construction of staff bike shed, while neglecting the more complex problem of the design of the plant itself. While this is a common problem in programming in general, TC39 considers it an important part of our process.
