Web Dev Tools 101: ECMAScript Version

You think you are writing JavaScript. Actually, you are writing ECMAScript v5 – also known as ISO/IEC 16262 or ECMA-262. ECMAScript v5 was released in 2009 with an adjustment (v5.1) in 2011. That means the majority of the world is writing their JavaScript in this language. However, there is a new specification on the horizon – ECMAScript 6 – scheduled for a mid-2015 release, and you can expect modern browsers to start implementing the new standard quickly once ratified. But should you be adding ECMAScript 6 to your arsenal or should you leave it alone for now.


it’s a great time to start dabbling in ECMAScript 6, but use a transpiler like Babel-core to compile your code to ECMAScript 5. The browsers are catching up and within a couple of years, you won’t need this step.

Why do I care?

ECMAScript 6 is around the corner, but it’s pretty much backwards compatible. There is a great browser support page here that looks at the language feature by feature. Some things you will want to take advantage of straight away, and some probably won’t interest you. Let’s take a look at some of the features of ECMAScript 6, with appropriate links to real-world definitions (rather than the specification, which is worth a read if you can’t sleep).

These are ones I will actually use, rather than all the little ones.

I’ll be doing a whole article on Modules since it explicitly affects how you write code. All this is good, but that’s a lot of red on the compatibility chart. There are two questions you need to ask:

  1. When are major browsers going to support ECMAScript 6?
  2. What do I do in the interim?

The interim is a long long time – we’ve only just got rid of Internet Explorer 6 finally. So there is a valid point here. If it’s going to take forever for major browsers to work with ECMAScript 6 because of upgrade cycles, why should I even bother?

To answer question 1, let’s take a look at the major browsers:

  • Google Chrome: Most of the ES6 features are hidden behind a flag called “Experimental JavaScript features”. Visit chrome://flags/#enable-javascript-harmoney and enable this flag. Restart Chrome and you will get a bunch, but not all, features. It looks like Chrome is heading in the right direction.
  • Mozilla Firefox: Firefox is already implementing much of the ECMAScript 6 standard. It should be complete within a couple of releases. Since releases of Firefox are close together, this means that it’s likely that Firefox will have close to 100% coverage by the time the draft becomes a standard.
  • Microsoft Internet Explorer: The Technical Preview for the browser that will be released with windows 10 is shaping up to cover practically the entirety of ECMAScript 6. IE 10 and IE 11 are currently distributed though, and they do not provide coverage. Microsoft has also publically stated that they won’t be upgrading those browsers to be ECMAScript 6 compatible.

The Kangax site shows a support matrix for pretty much all the major browsers.

Transpiling: The Next Frontier

So, you like the features of ECMAScript 6, but no-one supports them. The next best option, and likely the best options for a few years, is to use a transpiler. A transpiler in this context is something that takes ECMAScript 6 in and outputs ECMAScript 5. Just like any other compiled language, you don’t want to be looking at the output. Ideally, the transpiler you choose should have three features:

  1. Support for the ES6 features you want to use
  2. Source maps
  3. Integration with your task runner

A sourcemap is generally yourfile.js.map – it’s a mapping from the original source code to the transpiled source code. When you are debugging, you don’t want to have to think about where the error occurred in the original source code – you just want the debugger to tell you. Sourcemaps do that for you.

You can check out the Kangax web site for supported features – it looks for the transpilers as well.

There are two transpilers worth your effort – Traceur and Babel-Core. Both of them are pretty good and the compatibility is improving all the time now that the ES6 specification is locked down. Pretty much anything you want to do (except for maybe modules) is either implemented in the browsers or implemented in one of the transpilers.

Which one is better? Babel-core has better coverage, works with more libraries, is distributed with NPM and has support for Gulp and Grunt.

Someone is going to tell me off because I missed out Typescript.  TypeScript is a language by Microsoft and fully supported within Visual Studio.  You can also compile it using grunt or gulp.  Angular just announced they are writing their v2.0 application code in Typescript, and it has a bunch of ES6 features – actually most of them.  Plus it’s got the backing of Microsoft.   I’d use it as a transpiler and certainly they’ve made it easy.  But be aware of the features in Typescript that aren’t ES6, like interfaces. Those are not transportable, so you need to be aware when you use them.

The Verdict

Do you like working in the future or the past? The past is ECMAScript 5, but it will be here for a long time. ECMAScript 6 is the future, easy to pick up once you have a working knowledge of ECMAScript 5, and easily implementable.

Browser support isn’t there yet for ECMAScript 6. My recommendation is write in ECMAScript 6 and use the Babel-core transpiler to compile your code to ECMAScript 5.