For the most part, we have Browserify, Babel, and the spec being finalized to thank for. But we didn’t always have these tools and they weren’t born as mature as they are today.
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 never implemented ES6 modules. Earlier this year those projects merged into what we know as Babel today.
Come june, the spec was finalized.
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.