These are all questions I’m hoping to answer with this blogpost, but to make some sense of it all, we first need to go over some very confusing history and terminology.
You’ll notice that I will use both transpiler as compiler to describe Babel. I use them interchangably as I don’t think the distinction matters all that much. For a more detailed discussion on the matter, read the following stackoverflow answer
What is interesting to know (for reasons which will become apparent soon, please don’t abandon me yet) is that the releases of ECMAScript have been irregular to say the least. Version 3 was released in 1999 and version 4 was supposed to land in 2007 but didn’t because of politics or whatever. ECMAScript 5, the first proper update since v3, wasn’t released until 2009.
It still took six years for a new specification to land, but in 2015, ES6 (ECMAScript 2015) finally landed and it was a huge update. Besides bringing us many new features and improvements, it seems ES6 also kicked off a new era with a yearly release cycle. Instead of another seven years in hibernation, ES7 (ECMAScript 2016) was released in 2016 and is finalized by now, ES8 (ECMAScript 2017) was released in 2017 and is being worked on as we speak.
What we should take away from this story is:
- The versioning is really confusing.
Just so we’re clear, I’m going to talk about ES5 (ECMAScript 5), ES6 (ECMAScript 2015), ES7 (ECMAScript 2016), ES8(ECMAScript 2017) and whatever is next.
TC39 and stage-0 to 4
Now there is a yearly release cycle, it’s also interesting to know why and how new proposals and features are accepted in the language. This is done by TC39, which stands for Technical Committee 39 (such poetry). They’re largely responsible for maintaining and updating ECMAScript and they also evaluate and consider new proposals to evolve the language.
Changes to the language are done in a process which involves several stages:
stage 0: Strawman stage 1: Proposal stage 2: Draft stage 3: Candidate stage 4: Finished This is important to know as transpilers allow us to to use features in stage 0 to 3.
Transpiling vs Polyfills
You might ask: “Wait a second, isn’t that what polyfills do?”. Well yeah, but not exactly. As a rule of thumb, transpilers are concerned with syntax. Transpiling ES6 to ES5 will turn
var and your arrow function into a regular function equivalent. (I say equivalent because arrow functions and regular functions aren’t totally equal).
Polyfills take care of new objects and methods which aren’t compatible with older browsers. Think about the
Intersection Observer or if you really need to support IE9:
document.querySelector. These methods and objects all have polyfills to support older browsers and will not be handled by a transpiler.
Luckily for us, Polyfills and Transpiling goes together like lamb and tuna fish (I’m just going to keep using this until someone gets it), something the creators and contributors of Babel kept in mind when evolving the transpiler.
Babel began as a transpiler from ES6 to ES5. The differences between ES6 and ES5 were huge and especially at the time of release there were a lot of browsers which hadn’t implemented much of the ES6 features yet. Let alone browsers which never will be updated again (IE).
Does this mean Babel will become obsolete in the future as every environment supports all the ES6 features? Probably not. There’s a pretty stable ES release cycle since ES6 and Babel allows you to transpile ES7, ES8 and features which are still in one of the proposal stages. This way we’re able to try the latest features without them having to land in the browser or node first.
Babel is not bound to a specific build tool like Webpack. There are plenty of different ways to use Babel including in-browser, with a Command Line Interface(CLI) and with a range of frameworks and build tools. But the easiest way to try out Babel is visiting the Babel repl
If you navigate to https://babeljs.io/repl you can instantly start writing ES6 and see what your code is compiled into. In the panel on the left you’ll see the available presets.
Babel has a huge list of plugins that are used to transform specific ES6 features to ES5. For example, here is the plugin for transforming arrow functions. Installing all these plugins individually would be a bit of a pain, so Babel offers different presets which you can use to transform what you need.
ES2015 (ES6) - compiles your ES6 to ES5 ES2015 - Loose mode - loose mode produces a bit simpler and more readable ES5. Read more about it on the 2ality blog ES2016 (ES7) ES2017 (ES8) Stage 0 - 3 - Features which aren’t yet formally accepted into the standard yet. Be careful with using these as they can be killed or heavily modified before reaching the final stage. React - React? Yes, this is a bit of an odd duck, but React can be used with features in need of transpiling, one of which is JSX. JSX is not meant to be part of ECMAScript, but is a sort of extension on it.
The environment presets are great because they allow you to specify the environment you’re targeting. No more thinking about which ES version is which ECMAScript year, you just define the environment in which you want your code to work and the presets will take it from there.
Do note: When you want to use stage 0 - 3 or the React preset, you’ll have to activate those explicitly, regardless of other presets you might have activated.
Try it out
I urge you to try and transpile some of your ES6 code yourself as it’s very interesting to see how Babel handles new syntactic sugar like the ES6
Next week we’ll dive into using Babel in your project, using it in Webpack and so forth. If you want to stay up-to-date you can always follow me on twitter!