ponyfoo.com

A Brief History of ES6 Tooling

Fix

I wrote a few articles about React and ES6 these last few days, and today I wanted to add a bit more of context as to why I seem to be super into ES6 all of sudden. I’ve had an interest in ES6 for a long time, but we weren’t always prepared to write code in ES6. In this post I wanted to briefly touch on the history of ES6 tooling and why I believe that today we’re in a much better place to adopt ES6 than where we were half a year ago.

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.

Babel JavaScript Compiler
Babel JavaScript Compiler

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.

ECMAScript 2015 Spec
ECMAScript 2015 Spec

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.

Liked the article? Subscribe below to get an email when new articles come out! Also, follow @ponyfoo on Twitter and @ponyfoo on Facebook.
One-click unsubscribe, anytime. Learn more.

Comments (2)

Hugo wrote

Probably more relevant to your future article than this one, but my main concern is about modules in ES6/ES2015 that would force a full ES5 project to be also transpiled. I would be curious to know if source maps are fully solved since it has often been a problem on other transpiled languages and if there is significant time overhead during development for building on the fly code and source maps compared to ES5 + Webpack/Browserify.

I’ve seen many articles on the benefits of ES6 but surprisingly little on the cost of doing so. A more balance overview would be welcome.

Thanks again for all your recent articles. Short and opinionated, they feel dense in content.

Owen Densmore wrote

Module loading is a wreck and many are stoping short of using modules, just es6 to es5 via babel, still using

This at least is backwards compatible, letting me use es6 within an es5 project. Lots of others are using this approach.

Babelify, webpack, jspm. Pick one. Everybody. No module loader wars, please! And yes, be backward compatible.