JavaScript: 2015 in Review

JavaScript had a remarkable year. Despite reaching the grand age of twenty in May, news, projects and interest in the language continue to grow exponentially. Perhaps it's the strange circles I move in, but I can't think of another technology which moves at a similar pace. It's becoming increasingly difficult to keep up so I hope this summary helps…

ECMAScript Flipped

[author_more]

The seven-year long wait for ECMAScript Harmony or ECMAScript 6.0 ended in June 2015 with an officially-completed specification.

ES6 was promptly re-branded ES2015 although I don't know anyone who calls it that. The premise for the name change is good; 2015 was the year the specification was completed. JavaScript engines can now claim they're fully ES2015-compliant and everyone understands. Unfortunately, marketing-types won't like it one bit; no one's going to claim ES2015 compatibility as of January 1, 2016 when it sounds out-of-date.

What does ES2015 mean for developers? Prepare yourself for delights such as:

classes
enhanced object literals
let and const
arrow functions
template strings
iterators
generators
destructuring
proxies
weakmap and weakset
symbols
promises
reflection

Much of it is syntactical sugar. For example, JavaScript will retain prototypal inheritance but offer classical inheritance-like class structures for those ~~moaners~~ developers migrating from other languages.

ES2015 support remains patchy but it's possible to convert most code to ES5 using a transpiler such as Babel. It works well but that additional step can make testing and debugging more complicated. Personally, I'm a JavaScript Luddite who prefers to stick with the old ways until support has improved.

But forget about ES2015 for now -- let's move on to ES7/2016!

JavaScript Avengers Assembly

Hype reached fever-pitch in June with the announcement of WebAssembly; a low-level binary-packed assembly-like language for the web!

Delivering large applications to a browser isn't always practical. A game or complex program could require many megabytes of source code which is downloaded, compiled to bytecode and eventually run as machine code. WebAssembly makes the process more efficient by compiling source to a simpler, faster-processing, JavaScript-engine-compatible bytecode and packaging it in a compact binary file. Browser code will therefore load and start faster. It won't necessarily run faster than normal JavaScript but optimizations are possible.

We've visited binary land before. Flash, Silverlight, Java and Google Native Client (NaCl) all made a similar promises but WebAssembly should have a better chance given it: