What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
Super-fast S3 Express storage.
New Graviton 4 processor instances.
Emily Freeman leaving AWS.
I don't use AWS, so none of this will affect me.
Software Development

JavaScript 6 Offers Big Changes, and Kicks Off an Expedited Timetable

Mar 22nd, 2016 9:44am by
Featued image for: JavaScript 6 Offers Big Changes, and Kicks Off an Expedited Timetable

The language we build the Web with can officially develop as fast as the Web does.

Twenty years after the first version of JavaScript and six years after the last update to the official ECMAScript standard it’s developed into, we’re finally getting a new version of JavaScript/ECMAScript. ES2015 is the largest ever update to JavaScript.

ECMAScript 6 — now called ES2015 because that’s when the committee voted to adopt the draft spec — is important not just for the host of new features, but because it’s start of annual updates to the JavaScript spec.

It really comes out feeling like a new language,” said Jonathan Turner, who’s recently moved from running Microsoft’s TypeScript transpiler project to Mozilla. It’s also taken the longest to develop. “While ES5 was released 6 years prior, ES2015 is the culmination of 15 years of effort that started when the committee began working on the unreleased ES4 specification around the year 2000,” explains Brian Terlson, editor of the ECMAScript standard, and a senior program manager on the Microsoft Edge team.

That adds up to a wide range of improvements with more concurrency patterns and more tools for modular design and code organization.

The two biggest new features are probably modules and classes.

Using modules to organize your code is a basic programming feature that you previously needed to use extra tools to take advantage of in JavaScript. “Before you had to decide which module format you wanted to use; now you have a unified syntax,” said Turner. “The new module syntax gives developers granularity and flexibility; it gives you a very fine-grained way of importing because each project is a folder and each file is a module and you can just import the ones you want.” Turner believes that’s powerful enough to make it worth switching.

“The syntax takes maybe a bit of getting used to if you come from other module systems. But once you get used to it you can work with a whole module at a time or you can work with single imports at a time and you can build one module with submodules. You can have one module that flattens that API and multiple modules that are backing it into one flat API. It allows you a lot of flexibility in how you modularize an application, how you modularize a library or how you consume a library,” Turner said.

ECMASript 6 compatibility

“Modules are the feature I’m personally most proud of,” said David Herman, Mozilla’s representative on the TC39 committee that standardizes JavaScript, “and I’d encourage all JavaScript developers to give them a look. The state of the art today is to use them with transpilers like Babel, but as work on the WHATWG Loader spec proceeds, and as Node.js works out its implementation and interoperability strategy, we will start to see native implementations emerge both in browsers and Node. Regardless, developers can start learning and using modules in real, production apps today, thanks to transpilers.”

“Classes are great for building classical OOP hierarchies that previously took much more code and were less reliable,” added Terlson. There was plenty of debate about how classes should work in JavaScript, which resulted in some changes in the specification before it was finalized, but the result should seem familiar to both JavaScript and OOP developers.

“JavaScript’s object system is famously based on prototypes, and while it’s possible to emulate classes through prototypes, it requires a good deal of boilerplate and clutter,” Herman pointed out. “Even for small, one-off abstractions, I’ve found it gratifying to upgrade the age-old pattern of defining a constructor with prototype methods into a single, simple class declaration. At the same time, ES2015 classes are defined in terms of constructors and prototypes, so they are completely compatible with the existing object system and interoperable with existing code.”

Terlson highlights a number of other new features. “Built-in promises have paved the way for async APIs in the DOM and elsewhere to begin returning promises which is a huge boon to asynchronous programs. Generators are also key capability for certain async programming techniques and an all-around useful feature. WeakMaps give great capabilities to library authors especially.” Then there’s a host of small but significant improvements; Typed Arrays, new methods for String, Array, Number, Object and Math, new options for variables (‘let’ scopes a variable to the block you define it in) and — finally! — support for constants.

There’s also a lot of new ‘syntactic sugar’ in ES2015, from defining a function using the shortcut of typing => to the spread operator for auto-expanding arrays. Don’t be too quick to think that the style you know is best. “The various sugary features like destructuring, template literals, arrow functions, binary and octal literals, rest and spread, default parameters, etc. work together to make ES2015 code more terse, readable, and maintainable,” claimed Terlson, a sentiment to which Herman agreed.

“I’d encourage programmers to experiment with the many little conveniences and ergonomic improvements that make everyday programming tasks more pleasant,” Terlson said. “For example, parameter default expressions and rest parameters make the job of defining function signatures less tedious and easier to understand. Object syntax shorthands such as inline methods and default properties are another nice one. Each one of these conveniences may sound small in isolation, but all those ergonomic improvements can really add up, and, in my opinion, make JavaScript overall both a far nicer language to write code in and much clearer for reading.”

Transpilers; tools and testing grounds

If the major changes in ES2015, and the length of time since we last had a new JavaScript standard, make you expect a disruptive change, remember that it’s really a recognition of the continuing evolution of the language. As Turner pointed out, “you don’t have to buy into everything all at once and you can pick and choose what’s useful to you.” Even classes are really functions with syntactic sugar to make inheritance easier to work with, using familiar prototype inheritance.

Plus, even the new features aren’t entirely new to developers. The browser vendors haven’t waited for the standard to be finished to start work. Although there isn’t a single JavaScript engine that already implements everything, “the vast majority of ES2015 is implemented in the big runtimes (Chakra, SpiderMonkey, V8, and JSCore),” Terlson said (there’s a feature compatibility matrix on GitHub at where you can check support). “Developers that only need to target fairly recent browsers can use ES2015 today,” he suggests.

Those that can’t, can still use many ES2015 features in transpilers like TypeScript and Babel that will compile many ES2015 features to ES5 code that works in older browsers; “the vast majority of ES2015 features are available today in Babel, with the exception of a few hard-to-transpile features like proxies,” explains Herman. Unlike transpilers that define their own language, like CoffeeScript, or let you use languages like C and C++, like Emscripten (which turns LLVM bytecode into asm.js code), these produce JavaScript. TypeScript generates modular JavaScript, with explicit interfaces, with one file per class, where you can export namespaces and get code that looks like it was written by a developer rather than a machine, with a file for ES5 and another for ES2015 — and another for ES2016, when that comes along.

In fact, those transpilers have had ES2015 features for quite some time, and many of the new features have actually been prototyped in transpilers, so they’re already tried and tested.

“Transpilers have dramatically improved the JavaScript standardization process,” Herman claimed. “Historically, it was difficult to get real feedback from developers about candidate features, because of a nasty chicken-and-egg problem: browser vendors were reluctant to ship features that hadn’t been tested, but developers couldn’t afford to spend time building realistic apps using features that weren’t shipping in browsers.”

“With transpilers, developers can try out new features in their real production apps even without native browser support, which means the standards get valuable experience reports, bug reports, and usability feedback before it’s too late to change. And developers don’t have to worry about their code silently breaking because they get to decide when they’re ready to upgrade to a new version of their transpiler.”

“Tooling like transpilers is only going to get more important as the years go on,” added Turner. “If JavaScript is going to keep evolving really quickly, so there’s a new version every year, it’s going to be a challenge for browsers to keep up and it’s going to be a challenge to get users onto that new platforms that can support that new JavaScript standard at that rapid cadence.” Transpilers will fill that gap, giving developers early access to new features but allowing them to address browsers that don’t have the latest version of JavaScript from a single code base.

Both Terlson and Herman are confident that JavaScript developers who aren’t ready to move to the new standard won’t run into breaking changes and incompatibilities.

“The ECMAScript standards committee takes backward compatibility as an extremely serious responsibility,” Herman said. “ES2015 was carefully designed to cause no breaking changes to real-world code. The same goes for the browser vendors, agrees Terlson. “TC39 and engine implementers go to great lengths to ensure new language features do not introduce incompatibilities. Where the language has introduced incompatibilities in the past have been in edge case scenarios where we have data that no one or very few people are affected. In such cases, committee members or implementers will reach out to the affected libraries or sites to address the issue. Developers can sleep soundly knowing that TC39 is committed to not breaking their code.”

But with JavaScript now moving to an annual update cycle, and ECMAScript 2016 (with a much smaller set of new features) heading for standardization in June, most developers are going to want to start trying out the new features, and getting ready for a language that stays up to date.

Feature image via Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.