Before JavaScript-to-JavaScript transpilers became a (serious) thing, there were modules that would add specific bits of ES6 functionality to your apps. There were things like gnode, which allows you to use generators in node by interpreting your code during runtime (or turning on the Harmony flag for generators in node >= 0.11.x)

Trivia question: how many different names has ES6 accrued over the years?

Then we also started to see libraries that implemented ES6 module loading, such as es6-module-loader. These libraries helped advance the spec by giving developers something to chew on as implementations started cropping up. Of course, you could always use CoffeeScript or TypeScript back then which had implemented language features equivalent to those in ES6.

I didn’t care for the syntax in CoffeeScript, nor the fact that it would’ve effectively reduced my ability to contribute to open-source, so that one was out. TypeScript would’ve been okay but they have many features on top of what’s coming with ES6, and where possible I try to learn things that will be useful to me for a long time. That being said, both of these languages contributed to the shaping of ES6, so we have them to thank for that. There’s also the fact that for a long time, they were as close as you could get to trying a language with anything resembling the features in ES6.

Eventually, transpilers made an appearance. The first one was Traceur, and it came out around a time where the spec wasn’t locked down yet. It was constantly changing so it wasn’t a very good idea to try and use it for more than a few minutes to toy around with the syntax. I got frustrated very quickly while writing example code for my application design book. Around the same time, 6to5 started making waves and there was also esnext, but esnext never implemented ES6 modules. Earlier this year those projects merged into what we know as Babel today.

Come june, the spec was finalized.

Locking down the language features was crucial for adoption. It meant that compilers could now finally implement something and not have stale syntax within the next month. The spec being finalized and Babel becoming the de-facto JavaScript-to-JavaScript build tool got me interested in ES6 once again, so I started experimenting with them again.

We now have the ability to mix Browserify and Babel using babelify. We can use babel-node on the server during development – and compile to ES5 for production because performance reasons. We can use Webpack if we’re into CSS Modules, and there’s a bunch of ES6 features ready for us to use. We need to be careful not to overplay our hand, though. With this much going on, it’s going to be hard trying to keep up while maintaining a high quality codebase that doesn’t get every single new feature and shiny toy crammed into it just because we can.

There’s plenty of room in front-end tooling for feature creep, unfortunately, but we need to battle against that now.

Tomorrow I’ll be publishing an article about the parts of the future of JavaScript I’m most excited about and the concerns I have about mindlessly adopting ES6 features.