The Array.prototype.includes method – which checks if a value is included in an array or not — was originally going to be named Array.prototype.contains; it changed because that name was already used by the MooTools library, so reusing it might break some websites. There’s been some discussion as to whether that was the best decision, but it certainly reflects the emphasis the ECMAScript committee puts on not breaking code that’s already on the web.
Async functions were expected in ES16, but Terlson (who is what T39 calls the ‘feature champion’ for async) explained that the delay is due to the new requirement that new ECMAScript features have already been implemented.
“They’ve been implemented in transpilers for some time; Babel and TypeScript both support them, but today Edge is the only browser implementation. Until a couple of months ago that had a significant piece lacking, and the feeling on the committee was that without that we don’t really know that this is going to work on the web.” That should be addressed when Firefox adds async support and Herman predicts that “Async functions will hopefully get into the ES17 spec.”
Small and Ready to Use
The fact that ES2016 is “super small” isn’t a problem with the new process, Terlson said. “It’s very small, but that’s actually the process working. After ES2015, we had to get the pipeline filled with new proposals and those proposals had to go through the process and this year we could only get two of those things done in time.”
In fact, he suggests, the process is perhaps the most important thing about the new spec. “While the spec wasn’t that big in terms of new features, there were huge amounts of work done in other areas. We had on the order of a hundred web fixes, perhaps more even, and probably thousands of individual editorial fixes and tweaks. And that was all made possible by our transition to GitHub.”
Previously, although you could see it in PDF and HTML formats, the ECMAScript standard had been “lovingly maintained” in the same Word document, all the way from the original version one to ES2015. “That development method wasn’t scaling,” said Terlson (which sounds like something of an understatement).
“It was hard for the community to participate and hard for implementers to keep track of what was going on. We got out of Word and moved everything to GitHub, using a custom HTML dialect, Ecmarkup,” Terlson said.
That means that both proposals and the specification itself are in the same format; People can send pull requests for both bug fixes and editorial requests. “If you track where most of the work happened, it was building up the tooling and getting on board with the new tooling process, and that’s going to continue paying huge dividends,” Terlson believes.
The ES2016 requirement that features have to have had multiple interoperable implementations before they make it into the standard should save time further down the line.
“ES6 didn’t have the implementation requirement,” explained Terlson, “and as a result after it was ratified, as we got around to implementing certain features like proxies, there were issues implementers came across that were just not reflected in the spec, so we had to make changes after the fact. That really reflects the important of making sure a feature can be implemented as specified before ratifying the standard.”
There’s some debate about the level of implementation experience that should be required for a feature, and the process doesn’t specify that; “it’s done on a case by case basis,” said Terlson. “For certain features we can be pretty certain that they’re going to work if we get a transpiler implementation plus a browser and having them implemented behind an experimental flag is probably OK.”
Opinions vary but demanding more implementation would involve tradeoffs, he suggests. “We could require an implementation in two browsers shipping it, but that may mean when you discover an issue it’s too late, because it’s already shipped, and the standard would move more slowly because it would be gated by the implementers,” Terlson said.
What the new process does add are tests. “When ES2015 was ratified, there were no tests, so it took huge efforts to backfill them so implementations could test when they started building out features, that they were conforming to the specification.” For ES2016, there’s an official test suite and tests are required before a feature can become part of the standard. “We will never again be in a situation where implementers can read the spec but not know what the implications are,” claimed Terlson.
Take the Next Train
Terlson suggests looking at ECMAScript in a different way going forward because of the new process. “Developers shouldn’t be looking at the version of the standard as much; it’s really on a feature by feature basis,” he said. “On the GitHub repo, we have a table of proposals, and those proposals have varying level of maturity. If something is in stage three, that’s a good indication that it’s going to be a thing, and it’s something to be aware of. If a transpiler supports it, maybe turn that on and try it and give feedback, on a feature by feature basis.”
Herman suggests thinking of the yearly schedules like train timetables; whatever features are ready to use (which means they’ve reached stage four when the scope of the release is finalized, around January each year) go on the next train.
“The principal benefit of the “train schedule” to developers is that features can be finalized more independently and shipped sooner. The new process also provides clearer signals about the relative stability of individual features, allowing developers to test-drive experimental features in their apps via transpilers. This not only means developers get to take advantage of exciting language features sooner, but it also provides a feedback channel for improving experimental designs and amplifies developers’ voices in the standardization process.”
There’re other advantages, pointed out Jonathan Turner, now at Mozilla and former program manager of Microsoft’s TypeScript transpiler. “If each update were the size of the ECMAScript 6 update, that would be a gargantuan task to keep up with.”
“There’s a new technology idea almost every day; there’s a new framework that comes out almost every month. You can’t pick up every single one and run with it, but the community as a whole gets used to trying things out. Developers have side projects where they try technologies out, and they say ‘Oh that really did make things better’ or ‘Oh no, that’s got some rough edges,’ Turner said. “It’s really natural for things to grow organically across the community as people listen to each other and try little demos out with technology before they start rocking with it.”
Feature image: Unsplash.