This course has been updated! We now recommend you take the JavaScript: The Recent Parts course.

Check out a free preview of the full ES6: The Right Parts course:
The "Babel" Lesson is part of the full, ES6: The Right Parts course featured in this preview video. Here's what you'd learn in this lesson:

Kyle spends a few minutes showing which is an online tool that uses Babel to convert ES6 code into compliant ES5 syntax. While the command line version is better for development, the online tool is useful for understanding how ES6 code would be written in ES5.

Get Unlimited Access Now

Transcript from the "Babel" Lesson

>> [MUSIC]

>> Kyle Simpson: I just want to take a brief moment to mention the landscape of ES6 is complicated in a sense by the fact that syntax is not necessarily directly supported in every single browser that you may have to support. Now the good news is ES6 has been around for a while it was being prototyped in browsers all along during the spec process so many of the browsers that you support all ready support most if not all ES 6 certainly most of what we're covering today.

[00:00:36] There are a few obviously, a few corner in each cases and things. But [COUGH] if you have to support mobile or if you have to support older browsers, an IE11 or Safari 5 or something like that. If you have to support those sorts of browsers, the new syntax we're talking about like a dot, dot operator arrow function, whatever.

[00:00:57] It's not going to work and there's no real way to like gracefully handle that per say. So the typical strategy which most of you've probably heard of, but the typical strategy is what we call trans piling which is to take the ES6 code that you would write and to convert it into the equivalent that would have been in ES5.

[00:01:17] So it's kind of like the side by side that have already been doing, but doing that automatically for your code and this is a tool that you would run, this transpilers, a tool that you'd run in your build process right alongside your minifier right alongside the bundler tool that you use, your Linter any of those other ones.

[00:01:34] Any time you do a build process, you would package up the code in this transpiled form which means what's getting shipped out to your users not the code that you wrote, but rather the code that's been transpiring. Now the good news is that bundle of code will work in all the browsers that you need to support, cuz they're gonna target a version of JavaScript that's been around and standardized and well-known for five to seven years.

[00:01:59] The bad news is that there's a disconnect now between the code that's running in the code that you wrote. And whenever an error happens, an error actually happens in the code that you delivered to the browser not the code that you authored. So for a while now, we've had a solution for that, it's called source maps.

[00:02:19] Source maps are a special kind of file that basically is loaded by the developer tools of your browser on-demand or sent along with your file if you so choose, but it tells the browser, okay, whenever you see an error on line 12 in character 36, that's actually line 57 character 5 in the original source code.

[00:02:42] So, what the developer tool does is fetch your original code. The original author in six code and shows it to you in the browser instead of showing you the code that actually created the errors. So, source maps or a way to kind of virtually map layer on top of what's really happening in a developer tools.

[00:02:58] I'd say that's probably like a 90 to 95% solution. It's not 100% bulletproof perfect. It doesn't always catch all the different nuances and things like that, and sometimes your transpiler does stuff that you don't even realize that it's doing. Sometimes there are tricks that happen and tricks that they play that you might be debugging it thinking a certain set of code ran, and didn't.

[00:03:22] So, I just wanted to quickly show you one of the tools that's most common. I'd I'd say, probably 98% of people that do trans piling use a tool called battle and this is an online form of their tool that they have obviously a command line version of the tool.

[00:03:37] So I just wanna quickly illustrate with some of the code that we've already been talking about and you can see as I type the ES6 version of it on the left, you'll see on the right what the ES5 equivalent that we're getting. So image if we wrote something like function through that takes an x with a default value and it also takes a ...args and all of a sudden, you see it start to write some other code that we haven't I had to write and you see that that code is roughly equivalent to the kind of code that we were already talking about.

[00:04:12] So you kind of see that, it's already happening. So now let's say, we pop, we call a bar function and we're gonna pop in another value and then we're gonna spread out the args and then we're gonna pop in another value and pass those along to a bar.

[00:04:31] Now bar doesn't exist yet, but all we have to do is to find one. And now you see again, all of that extra logic that really needs to happen and make sure that stuff's getting copied over and sort of bullet proof spec, fully spec compliance stuff that you would have to be writing yourself.

[00:04:49] The reason I show you this is again to make the illustrative point. Both of these pieces of code accomplish the same goal. In a browser that can read ES6 like my Chrome can, I could deliver this code or I could deliver this code. But it's not so much about the delivery that we wanna care about, although the delivery is the practical thing, like how do I support browsers.

[00:05:09] The real question is how have we been writing code like this for the last 21 years of JavaScript's history? And hasn't that code been failing to properly communicate, because it's so cluttered up with so many details. It's so intertwined. It's so complexed with implementation details that the actual code underneath the covers the stuff that we really want to care about, the stuff that's over here on the left.

[00:05:34] We can't even see that stuff, cuz it's all mixed up jumbled up together with these other things. That's the value of writing ES6. It's not about shiny new toys. It's not about saving characters. It's about making code that gets out of the way, all the stuff that doesn't matter, so we can focus on the stuff that does.

[00:05:53] One little note of caution here when you look at a tool like Babel. There will be times where you type in a piece of code into Babel and then you look at the transpiled output. Now I fully recommend that you ought to do that, you ought to go and look and understand things or whatever, but take it as a guide not as a spec compliant one to one mapping.

[00:06:18] Because what Babel is doing is a very sophisticated set of analysis on top of your code and they're taking the shortest path to getting just your code to operate correctly in an older environment. They're not necessarily adding in all of the spec compliant details. Because if they can figure out that you don't need a spec compliant detail, they leave it out.

[00:06:41] So they do all kinds of analysis to take the shortest path and do optimizations, and tree shaking to eliminate dead code. All kinds of crazy things that they do in their outputted code that is not necessarily the same equivalent as what you might write, if you were trying to write spec compliment equivalents of your own ES6 code.

[00:07:00] Now, I regularly get people. Once a month or twice a month, I'll get somebody that will email me or tweet me in the be like hey, you said this thing on one of your workshop where does this and Babel says different. [LAUGH] You must be wrong. The fact of the matter is that Babel's not tasked with producing compliant code from a spec perspective.

[00:07:22] Babel's tasked with producing code that behaves correctly and as performantly as possible, that's what we want out of a tool. We wouldn't want a tool that produced crappy code. We want it to produce the best possible code that it could. So while it's informative to look at those differences, don't necessarily take that as your official education on how ES6 equivalents work, because they're doing a lot of analysis that you normally wouldn't do and a lot of new ones that we don't even cover in our discussions.

[00:07:49] Does that make sense? So, that's Babel I fully recommend that you look into that tool. Start using that, because what I'm teaching you about ES6, I want you to start using today. I want you to go back in and there's low hanging fruit simple stuff like dropping in the dot, dot, dot operator and dropping in a default value here and there.

[00:08:09] You don't have to completely remake your entire code base from scratch with arrow functions and proxies, and all of that other crazy stuff to get value out of the ES6. You can take small little parts and convert one idiom at a time, one declarative form at a time.