The Era of Transpilers
ECMAScript 2015 is just around the corner. Previously called "ECMAScript 6", it is the next chapter in the evolution of the JavaScript programming language. It is a major release that will change the way we write JavaScript programs on the various platforms, including the server, the browser, and other devices.
#The ECMAScript 2015 Standard
The most notable feature of ECMAScript 2015 is a direly needed native module system that allows for properly structuring code. Furthermore, there's a plethora of useful language features like arrow functions, classes, and template strings. Finally, ECMAScript 2015 includes many smaller additions like block-scoped variables and for-of loops that should've been part of JavaScript from the get-go.
In sum, all ECMAScript 2015 features make for a vastly improved language, and we should start using those features today.
The problem with this, of course, is browser adoption. While we're able to control our server-side JavaScript versions, it can take a long time until the new language standard is widely supported by all major browsers. Even in 2015, we can't assume ECMAScript 5 everywhere, despite its standardization dating back to 2009.
#Using a Transpiler
Having been worked on for several years, ECMAScript 2015 is going to be a huge release. However, it'll probably be the last version with such a big scope. Going forward, the responsible committee plans to standardize future JavaScript versions on a yearly release cycle.
I'm convinced that we're going to see a growing usage of JavaScript transpilers as a result of more frequent language updates. Instead of constantly waiting for browser engines to catch up, we can leverage transpilers like TypeScript, Babel, or Traceur to be able to use tomorrow's JavaScript features today. Some of those transpilers have been around for quite some time now and are successfully used in production.
Let's look at TypeScript, for example. In addition to providing optional static typing for JavaScript, TypeScript allows you to specify a JavaScript language version as a transpilation target. When targeting ES3 or ES5, unsupported language features from ECMAScript 2015 will be rewritten in a way that older JavaScript engines can make sense of them as well.
Once you decide that ECMAScript 2015 — or whichever version your code is written in — is supported widely enough for your purposes, you can simply change the transpilation target to a higher language version and have your code constructs emitted unchanged. This way, you can rely on native implementations rather than compiler-generated, lowered code.
#Integration with Build Tools
In modern front-end development, the JavaScript code that's executed by the browsers usually looks very different from the code that was originally written. We bundle and minify our script files to reduce load times and page size, thus making them almost entirely unreadable. The same goes for stylesheets that are transpiled from Sass (or Less, or Stylus) to pure CSS, auto-prefixed, bundled, and then minified.
To transform our static assets in that way, we use task runners like gulp or grunt. Because of that, it's easy to integrate a JavaScript transpiler into the build process as well. We already have a build system in place anyway, so there's no big overhead in adding a transpilation step. Five years ago, that was not the case.
If you haven't yet used a transpiler for your JavaScript, now's the time to pick one and give it a spin. Babel is a great choice if you just want to explore the new ECMAScript 2015 features. It's an active OSS project that works well with modern build processes. TypeScript, on the other hand, is great if you'd additionally like to have the benefits of a statically typed language. Either one works fine.
tl;dr: ECMAScript 2015 brings a lot of goodness. Start using it today.