The recent surge in popularity of ES6 transpilers such as Babel (formerly called 6to5), combined with the fact that ES6 has adopted several of CoffeeScript’s improvements to JavaScript, has resulted in the meme that CoffeeScript is now obsolete and is due to be replaced. Does that really follow?
Let’s step back a second. At a high level, Babel and CoffeeScript are two programming languages that compile to JavaScript. Importantly, they both compile to a version of JavaScript that you can use today with older versions of Internet Explorer.
They are not alone. There are many, many other languages that do this.
CoffeeScript is notable for being the most popular language that compiles to JavaScript. Babel is notable for being a language whose design is intentionally identical to a version of JavaScript that is not usable today, but which is assumed to be usable without a compilation step at some point in the future.
The blurb on babeljs.io lays it out:
> Babel will turn your ES6+ code into ES5 friendly code, so you can start using it right now without waiting for browser support.
Clearly Babel is marketed as something meaningfully different from CoffeeScript. The logic goes something like this:
- We need to support older versions of Internet Explorer, but that means we can’t use all the nice features modern browsers have added to JavaScript.
- To solve this, we will add a Babel compilation step to our build process. Thanks to this minor effort, we get to use a nicer version of JavaScript right now!
- Someday browsers will catch up, we will no longer need Babel, and we can breathe a collective sigh of relief as we remove the compilation step from our build process.
In other words, Babel is a significant convenience that we should add to our build process as soon as possible, while simultaneously being a significant inconvenience that we should remove from our build process as soon as possible.
When confronted with this logic, I personally feel the need to pick one conclusion or the other: either adding a Babel compilation step is a significant inconvenience or it isn’t. And for my money, it simply isn’t.
In a hypothetical future where I could use ES6 features without a compilation step, I’d still want Babel for the new ES7 hotness that only half the major browsers had natively implemented. Our collective thirst for sharper programming tools will not end with the mass adoption of ES6, I promise you.
So if the Babel compilation step is never going away, and wasn’t much trouble to begin with, then what makes Babel meaningfully different from CoffeeScript? Aren’t they both just two different programming languages that compile to JavaScript?
Yes. Yes they are.
As with any two programming languages, there are pros and cons to each, but they can be compared on the same level as any other two languages.
Some of the tooling for Babel is nicer. For example, you can use many of its ES6 features in a modern browser’s console without needing an extension like CoffeeConsole. But there’s far more to language tooling than what browsers natively implement; consider Elm’s time-traveling debugger, which we can hardly expect will ever appear on the JavaScript roadmaps of any major browsers.
Some of the features in CoffeeScript are nicer. Everything is an expression, a benefit which would so severely break backwards compatibility that there’s little chance any future version of JavaScript will introduce it. Of course, some of the features in Babel are nicer too; let and const are both useful, and CoffeeScript has no plans to incorporate them.
Again, tooling and features are normal ways to compare two programming languages. There’s nothing intrinsically wiser about choosing Babel over CoffeeScript, because Babel isn’t special. It’s just another language that compiles to JavaScript, with its own unique set of pros and cons.
And that’s exactly how we should treat all ES6 transpilers. Decide whether to adopt them based on their merits as languages that compile to JavaScript, and nothing else.
Discuss this post on Hacker News
Richard Feldman
Engineer at NoRedInk
github.com/rtfeldman