A Year (plus a little) on TC39
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.
Don’t break the web
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.)
The naming of things¹
An average meeting
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.
The real work starts
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
- 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.