Written by on 22 June 2015

Jumping the ES6 bandwagon

June 17th the final version of the ECMAScript 6 standard was released. Officially it was recently renamed to ECMAScript 2015, but I sincerely doubt anybody is going to use that name. I’m not going into detail about what ES6 is all about, because the standard has been in use long since before its final release. There are however still no JavaScript engines that fully support ES6, so you have to rely on so-called transpiling: automated translating of the code to another language. And in this case you will be transpiling to ES5, a version that is supported by all major platforms. If you have been working with CoffeeScript or TypeScript, you are already familiar with this concept.

There are several tools to accommodate the transpiling. Google has it’s own tool called Traceur and Facebook has it’s JSTransform. One of the most popular choices however is Babel. JSTransform supports JSX transformations, but has limited ES6 capabilities. Traceur is very complete, but does not support JSX. Babel basically combines the best of both with JSX support and a very complete set of ES6 features and polyfills.

To transpile or not to transpile…

The big question that arises is whether you should use these tools in production. Essentially you are just ending up with ES5 you could have written in the first place. So let’s look at a few of the pro’s and cons.


  • Your code is future proof. You will be writing ES6 and in some time from now (probably several years) you can simply unplug your transpiler and start using your code as native.
  • You and your team can already start learning the tools of tomorrow. You can make the new syntax your own and become an expert long before it will be natively available.
  • And obviously, ES6 is just extremely cool. You get a lot of shorter syntaxes and added functionality. Great conversation material too for those nerdy birthday parties.


  • You are not actually accomplishing anything, because your output is still ES5. And often a lot more of it.
  • Not all features are able to be transpiled. A lot of functionality gets transpiled to simpler implementations or when they conflict, will give transpiler errors on building. Using let or const for example will simply be rewritten to var, with some transpiler magic. For other new features you will still be implementing polyfills, like for Promises or Symbols.
  • You add a layer of abstraction to your code and you will be reliant on generated sourcemaps. If you run into some weird bug you can never really be sure if this is in your ES6 code or the ES5 output.
  • The transpiling process adds extra overhead to your build process, of which you can already question if this is the right place to do this. Because you cannot feature detect in your build tool, you end up with the same ES5 code base even if you just want to support a single old browser. And with “old” I mean all current browsers.

No good or bad choices

I’m not advocating using, or not using, transpilers. However it is a choice not made lightly. See what the advantages have to offer in contrast to possible disadvantages. I can imagine that refactoring an old application might not be the highest of priorities. If you are starting a brand new application that will be maintained and extended for a long time into the future, you are probably a lot better off.

Most importantly, there is no shame in sticking to ES5. It might even be the best choice in a lot of environments. Our Node.js team for example is using features when they come available in V8 natively, and chose not to blindly implement ES6 features through transpiling. On the other hand if you are building new React applications ES6 is a fine choice, since you will be transforming your JSX anyway in the same pass.

COMMENTGive your two cents.