02:28 - Sebastian McKenzie Introduction

02:53 - Babel (Pronunciation Clarification)

05:56 - History

09:14 - The State of Babel

09:59 - Babel and the TC39 Process

11:54 - Features That Can’t Be Transpiled

13:45 - Readability and Performance Output

18:12 - Plugin Architecture

19:58 - ES6/2015 Feature Implementation

25:49 - The Birth of Babel

26:45 - Babel vs Traceur

28:08 - Future Babel Features

30:15 - The Status of ES2015 and ES2016

31:01 - Browser Support

35:03 - Marketing 

35:59 - TypeScript

37:24 - Babel Development and Labor

Picks

Primitive.io (Joe)
Armada: The Novel by Ernest Cline (Joe)
How to Win Friends & Influence People by Dale Carnegie (AJ)
Web Security Warriors Podcast (AJ)
Nodevember (Aimee)
The Hitchhiker's Guide to the Galaxy by Douglas Adams (Dave)
Yellowstone National Park (Dave)
React Rally (Dave)
Iterativ: AngularJS Kurs (Chuck)
Hire Thom Parkin! (Chuck)
The Martian by Andy Weir (Sebastian)
Five Guys Burgers and Fries (Sebastian)

Special Guest: Sebastian McKenzie .

 

Do I still sound like an angel, gentlemen?

Hey everybody and welcome to episode 171 of the JavaScript Jabber Show. This week on our panel, we have Aimee Knight.

Hello.

Joe Eames. Skype hates Joe Eames. AJ O'Neal.

Yo, yo, yo. Coming at you live from Provo for one of the last times in a long time.

Dave Smith.

Hey, everyone.

I'm Charles Max Wood from DevChat.TV. Jamison is not here so I'm just going to mention it for him. React Rally, go check it out.

Woohoo.

We also have a special guest this week and that's Sebastian McKenzie.

Hey.

You want to introduce yourself?

Sure. My name is Ses McKenzie from Australia. I made some JavaScripts thing that people use.

This JavaScript thing, yes.

That's being modest. [Laughter]

There are like two people use it. [Laughter]

I like JavaScript things.

[Laughs].

So you want to introduce us to Babel real quick?

Yes.

Or do you call it Babel?

Yes, could you just set the record straight and tell us how to pronounce it?

Yes, it's Babel. I didn't think it was going to be so much controversy over how the name is pronounced.

Why is it Babel? That's what I want to know.

As in like the origin of the name Babel?

Yes, why do you pronounce it Babel?

No, I think he means the origin of the pronunciation. [Laughs].

Oh.

Oh, the origin of the pronunciation. Yes.

We're superficial here. Yes.

All right. It seems like random people either pronounce it Babel or Babel depending. It's not even regional. I've found some Americans pronounce it Babel or Babel or like yeah, I don’t know. That's just how I pronounce it so.

Does anyone pronounce it 6 to 5? [Laughter]

So I got a funny story about the pronunciation. I thought of course, like the tower it was named after the tower, of course. So I've grown up pronouncing it Babel. And I'm telling other people, "No, it's pronounced Babel. That's how you pronounce the tower." Actually, somebody looked it up with the dictionary and like, "Both pronunciations are acceptable in the,” I don't know, “Oxford English dictionary.” It's says both Babel and Babel work. And I had no idea.

[Chuckles] Yeah, a lot of people like “Ah, isn’t’ that how the tower is pronounced?” I’m like, “No, I pronounce it Tower of Babel.”

Yeah. So there are people out there that pronounce it the Tower of Babel which is obviously wrong because I pronounce it Babel. [Laughter]

I was so shocked to find out that like my pronunciation wasn't the one blessed pronunciation of the Tower of Babel.

[Chuckles]. All right let's see if you can hear this. This is off of Merriam Webster.

Babel]

So Merriam Webster says Babel.

Okay.

Well, enough about that.

So the important things facing the JavaScript community today? [Laughter]

You know what, this is actually a really big deal because I was recording a course on webpack and Babel is a huge part of that. And I recorded half the course pronouncing it Babel and had to go back and just place in the word Babel in like 25 places.

That's hilarious. [Laughter]

Yes, it took like two hours.

I can totally see you just prepping for those outtakes. Babel, Babel, Babel, Babel, Babel, Babel, Babel.

Oh, yes I was going ask about the outtakes whether or not you had just spliced in like a single sample of [00:4:55 Inaudible].

Yes, the same. [Laughter]

Those are filled very obviously.

Yes.

Same clip over and over again.

And here we’re going to splice in Babel. [Laughter]

The volume's wrong. The pitch is all wrong. Early in the morning when my voice is all husky.

Just get someone else to say the word for you.

Yeah. [Laughs] Even better. Dave's not saying Babel.

Well, I'm glad we had this show. That was good. Did we mess it up? [Laughter]

That's pretty much the one thing. Other than that everybody uses this. I think we could be done.

Yeah. No.

So, I'm sure most of our audience already knows what it is but why don't you give us a very brief overview of what Babel is.

And the history.

And why it would benefit us.

Yes, maybe a little history for fun.

All right. So Babel started off as a project called 6to5. So I basically started this project 6to5 because I realized those are what looked like gaps in my knowledge of various computer sciencesy stuff. So I didn't know how passes worked. I didn't know how compilers worked. And also I was familiar with JavaScript. I knew JavaScript but there was this new thing coming out, could be ES6, and I didn't know anything about that.

So I started really low level ware. I’ve decided on to learn about this stuff so I combined it all together and decided, hey, could I transpile ES6 into ES5. I wanted to use these features. I want to know how they work. How can I do this? So I started really low level ware. I would take these really, really simple ES6 features and compile them down.

So it just started as a learning project and then people started using it. There was like billion features. Then people started using it so I thought I'd build up the support. And then I didn't recognize that's what the whole range of ES6 syntax. So it started to build up. People started using it. I'm like, "Oh, this is becoming like a real thing.”

And then I realized that the name 6to5 wasn't really very forward thinking. So once ES6 was common place, it would have to be like 7to6.

And 7to5

Yes, it was 7to5 and then like…

No, it's 2015to5.

Yes, exactly, like they've renamed ES6 to ES2015. And so it would have to be ES2015to5 and then like you have the name them just like. If you're going to sell the project, don't base conversion numbers. That's just so dumb, I mean, hindsight.

So then it was renamed to Babel and with the rename became Babel recap. It started becoming much more generic and what it did. So, instead of just being a uniquely ES6to5 compiler, it added support for plugins. So it became yes just a more general JavaScript compiler.

So eventually in the future, Babel will be able to do stuff like modification, optimizations, and all stuff like that. Basically they will just plug in these transformers that transform your code in specific ways just by installing an NPM module and specify it in your config.

That is so cool. I just love it. You're inspiring. I just want to make sure everyone caught that. The reason he wrote Babel or 6to5 was because he didn't know how to do it. Not because he was already an expert. I mean that is just so cool, Sebastian. My hats off to you.

Thanks.

So, on a project like this, where do you start?

When I started, there's a whole bunch of libraries relating to this, so I just hodgepodged them together. I didn't really understand how they worked. But then as the project grew, I rewrote those libraries and so they replaced other people's code with my own. Things like most projects come and go in the other direction. But it's mainly just like I want to learn about this stuff and what better ways write it yourself.

So what's the state of Babel now? You mentioned that it's implemented almost all or all of the ES6 feature set.

Yes, so it's past the entire range of syntax. Eventually in the next major version, it’s going to be a big push into these plugins. And so like this plug-in ecosystem I think is going to be a big thing. It separates Babel from anything else like you hear about other compilers or transpilers likeTouchScript or Traceur. I don't like using the web competitor in my space but I didn't really see those projects as competitors because Babel's scope is much different. Its utility is much different compared to the other tools out there.

So I had a quick question. As we're talking about the supported features, how does Babel line up with the TC39 process?

Yes, so like how a proposal’s developed in tandem or…

Yes. How do you decide what you want to support based on the process and things going through TC39?

Yes, so -- oh, I will just give you the background of the TC39 stage process. So the TC39 committee, when a proposal is put forth for standardization, there's a series of stages that has to go through from zero being like just anybody had just written a proposal to stage four where it's in the language. It's been standardized and it's absolutely going to be included.

So each one of these stages signify something. So stage one it's being accepted by the TC39 for more investigation. Stage two is it has multiple vendors have implemented it so multiple browsers. I might be wrong with this because this is like the spread out of each stage. Stage three is it's being accepted. It's still in the draft stage. Then yes, stage four is where it's being finalized.

Babel by default has stage two proposals and above enabled by default. Now that doesn't signify that these stage two and stage three stuff is absolute guaranteed from inclusion. But in order to promote experimentation with those features then they have to have users. It's much easier for people to use it if it's enabled by default, I guess.

And so stage four proposals is implementing Babel. They’re just behind flag. They’re subject to change. You probably shouldn't be using their production code but you can if you want, I guess, just have to be worried that if it gets rejected then it's probably going to go away.

You said that it implements all the features of the ES2015. Are there any features that just can't be transpiled?

I guess there's varying levels. So there are some things that Babel just can't transpile. It can't implement every single edge case or semantic. So for example, like RR functions [inaudible] as being a very straightforward thing to transpile. Like, “Oh it's just a function.” This and arguments reference like the out of function.

What's not so simple, you can't for instance construct an RR function so you can't do new foo where foo may be an RR function and so these sorts of things you can't really like transpile, at least not in a like a practical way.

If you really want to care about performance and you really want to care about code size and you have to make some of those sacrifices, it might not necessarily mean you’re just making it, it's a deliberate choice. It might just be that there's no way to implement those semantics in ES5. Since if something is just syntax [inaudible] for something else. If you're going to be directly compiled and have all the exact same semantics then it might not be reason enough for it to actually be in the language itself. It can be expressed in a different way very easily.

So like things like Weak Maps come to mind. What about that?

Yes. So Weak Maps and proxies, they're both true good examples of stuff. So they have more runtime things. They're not really syntaxed but yes, they implement semantics that absolutely have to be implemented at the engine level. You could actually compile proxies but the transformation would be much more intrusive. Weak Maps, you can't really do anything since their wired like direct access to the garbage collector and stuff like that.

Now I had always heard and thought that one of the big reasons for Babel was the fact that the output of Traceur was just so unreadable. And Babel always had a goal of producing readable codes so then it was easier to reason and to understand the code that was produced by the transpiler. Is that true?

Yes. I guess. That was the really big thing when 6to5 was released. That was one of the things that set it apart. That's not to say that the output isn't readable now. Just other priorities have shifted above just readable output. If you're just focusing on readable output, you're making way too many sacrifices on stuff like code size and performance. Since you can output more performant code, it will just be longer or the code, it might not be as readable.

So, at that time it made sense. But now it's just like you really shouldn't be reading your compiled code anyway. That's just what it comes down to. There's lot a magic that goes on under the hood in like compilers, transpilers. So you might look at something and think, “Oh, that's wrong.” But actually if you just change one little tiny thing, it can completely change the way that the code is transformed to an output.

So it was a goal initially but not so much later on.

Yes, basically. Like if it came more down to it, would you care more about your code being pretty or your code being as fast as possible?

So do you usually like have a balance between readability and performance or do you almost always go for performance?

It's basically always for performance. There's always going to be ways in which you can make the performant code much nicer. And it depends on what you mean by your general code being nicer. Most of the time it’s just you just have to put more effort into it like you have to add in more conditionals that checks specific structure of the original code. Since there can be some certain scenarios where the original code can be compiled into a completely different set of code that’s much more readable. And so I definitely think yes, you just have to put more effort into it but definitely, you don't really need a sacrifice readable code to get really good performance. But performance is basically always the priority. Since if you can't trust Babel for a performance then that's failed, I guess.

I'll be honest. I haven't particularly looked at the output of Babel recently. I have, actually on a couple of times recently, looked at Traceur. Would you say that Babel in general is still more readable than Traceur? Has it gotten to where its, like Traceur, there’s some crazy stuff in there.

Yes. So I think actually one of the problems that Babel will try and retain new lines like in between code, it retains those new lines. So if you're separating your code visually to the list of new lines they’ve retained where Traceur will just blow them all away so your code just looks like one after the other. So there are no new lines in between the spacing.

I'm pretty sure this may have changed but they don't retain comments which is another big thing. I know in the Angular community, they use it for dependency injection. So that's another scenario where just having readable code and retaining as much about the original code as possible can lead to better utility for the consumers.

You know that's interesting. I didn't realize it was filling out of formatting so much. I actually was just talking about just cracking the actual code that Traceur produces like just looking at it and understanding what the code does. It does some crazy stuff in there that you have to really sit and stare at to try to figure out what in the world it’s actually doing. Do you feel like Babel is like that?

In some scenarios, I think so. So I've recently, with a focus on mobile performance, if the code looks more complex and it's more hard to understand but it's much significantly more performant then the more performant route is going to be taken.

At the end of the day, you shouldn't really be learning from transpiled output if that's one of your goals. I said before how the compiled output can change significantly depending on small structural changes and so you may become misinformed if you're learning based on the compiled output; or if you're just debugging stuff then that's the pain. But again, we have source maps and that alleviates basically almost all the pain.

Right. That makes sense.

Now you talked before a little bit about Babel heading into this plugin system where it will do all kinds of things. I know that you know right now it does all kinds of stuff like JSX that isn't necessarily a transpilation as we think of it. But that's funny to me because I associate Babel as a plugin into something else. So Babel becoming a plugin into some other framework but then it has its own plugins.

It's just plugins all the way down.

It's plugins all the way down.

Yes, yes. I think I got what you're saying. So you say Babel is not something that's built on another platform rather than Babel itself being a platform?

Yes, typically like I use it within webpack or from [inaudible].

Oh, right. Yes, I guess it's sort of like that. But that was actually one of the decisions that I knew this was the direction that made most sense to the project on whether or not I'm creating a new one and then having this set of ES6 transforms on top of this. And it didn't really make much sense and so like in the next major version of Babel, basically nothing is going to be enabled by default.

You don't have to opt-in to each transformation.

Sounds familiar.

No, I mean the ESLint project is doing the same thing, right?

Yes, exactly. It's a much more powerful approach. You're not as opinionated. And in order to facilitate moving the internal modules out, you end up having to create a really powerful public API that can perform the same functionality that you were using internally. So not only does your system become much more plottable but also because it's much more stable and powerful as a consequence of just removing these things out.

So what was one of the ES6 or ES2015 language features that you found the most difficult to implement in ES from going to 6to5?

Which one made you curse Yehuda Katz? [Laughter]

This is on my list of questions too. I really wanted to know this.

Probably block scoping so Let and Const. There's a lot that goes into it. That's the one transformer or one feature that is being iterated on a lot. I'm like, “Okay, I think I'm done. I don't think there's any bugs in this.” Then I'll be like or wait a couple of weeks where I go, “Oh, so good.” It's stable and then I'll hear something really fundamentally broken about it and I would just be like, “Oh, shit!” And then I'll have to go through and rewrite it. I think I've rewritten it probably about four or five times now, mainly just because the logic becomes so dense. And in order to produce the best output, the most clean, a lot of effort has to go into it and a lot of edge cases need to be handled to output the simplest code.

So like with Let and Const, you just end up having tons of functions nested?

Yes. Like even just like wrapping stuff in functions is it seems easy but then you have to account for what if the thing that you're wrapping has a return in it. What if it returns from the function you've just wrapped it in function so you then have to propagate that return?

But what if it's a continuous? So you're continuing from inside the loop that has to be done as well. But what if you've got break that also has to be handled? But then what if you have labels? I’m surprised by how little people know about labels in JavaScripts. Labels allow you to just label a loop and then break out of it when you've deeply nested it.

Oh, yeah.

And so they need to be handled as well. So you end up having to like re-implement all of this stuff where you're just propagating a whole bunch of stuff and this is just all consequence of you just like wrapping it at a function.

What about exceptions? Were they hardly there too?

Exceptions also like bad…

Your system?

It's a merely inadvertent function that's not like a sync stuff going on so that just works but I think block scoping has definitely been the one that's being very painful.

That sounds really hard.

Yes.

What about destructuring? Was that hard to do?

Not really. Destructuring is fairly straightforward on what it turns into. Some of the semantics is overlooked. So when you're destructuring using the array destructuring, it can actually take in any iterable object. So, that iterable object - it could be an array, it could be a generator. In order to support that, you have to output some extra code. Babel does that by inserting little helpful functions at the top of your file and then it uses those so as to like outputting the code multiple times.

Oh, yes.

So it pants a lot of that stuff to the runtime mainly because you just can't tell when you're compiling it. Like at compiled time, what that's going to be. Yes, so that stuff is fairly straightforward.

Just make note everyone. Sebastian said destructuring was easy.

That's easy. [Laughter]

Do you find yourself constantly going back with some features and implement it and then you discover new used case then you have to change something. And then you go through this 50 times and still waiting for yet one more scenario you didn't think of?

It was very much like that at the start of the project ES 6to5. The JavaScript language has a specification that basically lists out everything that should work. It's very specific. When I first saw the project, I had no idea how to read any of that stuff. I was forced to because people are like, “Hey, your behavior is wrong.” I’ll be like, “Why? Prove it.” And then they'll link to the specification and I'll be like, “Ah, this thing does this, this does this.” So I’m going to be like, “I don't understand this. I’ll take your word on it.” And so it forced me to learn how like how to read the specification.

And I feel confident now that if I would implement a new feature, I could follow it exactly from the specification to catch all possible cases. So if something just wasn't supported didn't work, it would be a consequence of just a bug rather than lack of oversight of that specific feature.

So do you like to read this spec now for fun?

Not so much for fun. More like when people yell at me that something's broken or not behaving correctly.

Speaking of the spec, do you ever feel like you're engaged in a Sisyphean task of doing all this work only to have JavaScript runtime implementers subsume your work by implementing it natively. I mean eventually every feature of Babel or Babel, excuse me, that exists today should be obsolete, right? When runtime's all picked it up natively?

I'm not quite as pessimistic in my thinking of a lot of this stuff. So I guess that goes back to that Babel is more than just like an ES6 compiler. It can do more than that. Babel is basically always going to be bleeding edge. It's always going to support all the latest and greatest features and all the proposed features before they're basically in any native runtime.

And not only that, people you're probably going to be supporting all the browsers to the end of time. There are little mobile browsers so then that I think they’re rarely updated especially in the most third world countries that have much older phones that it’s hard for them to have JavaScript like on them let alone like the latest version of Chrome. There's always going to be room for compiling this down.

I don't see this like a bad thing. It's a standard for reason. It can be implemented in browsers much more performantly. So I think Babel has barely a niche there and it doesn't become irrelevant just because the browsers support this stuff.

Makes sense.

So cool story that I heard that I think would be interesting to share. You want to tell people how you ended up getting into Babel, why you started writing it?

Yes, so I've read there’s a bunch of projects right as I was finishing school. Yes.

You said you just got bored in class and you did this just to like stay productive while you were in class or what?

Yes, I was finishing my final year exams. I didn't really like school. It was boring. When I was in like history class not listening, I was doing Babel which at the time I was really stupid. I should be practicing my school work but I was this incredibly lucky where it's paid off.

Maybe.

We have, we have your boring teacher to thank. [Laughter]

Yeah, thank you.

Yes.

You should just say you're really good at multitasking.

I wish.

It sounds like he was single-tasking. [Laughter]

Yeah. Okay so one other question I was going to ask. When we started talking about Traceur earlier, I feel like most people know this but just in case, can you talk about the difference between Traceur and Babel?

Yes, so Traceur is just like just a normal ES6toES5 compiler. And so Babel is more flexible in the plugins. So I've talked a lot about that.

The actual difference is between how it transpiles. So Babel supports a much larger range of features. So a lot of the latest proposals implementing Babel, they're not necessarily implemented there. A big difference is I think it's increased adoption Babel is like Babel's very easy to use. The docs are very clear in how you use it with your various integrations like your module system, your build system. There’s plugins folder to make it as easy as possible.

I've personally before I started Babel 6to5, I tried to use Traceur and I just couldn't get it to work. I've seen a lot of people have the same experience with it. It's an awesome project but very hard to use. There's lack of documentation. And so yes, that's probably the biggest one and the readable output is supporting more. Yes, it is the big difference I think that sets the projects apart.

So you talked about making Babel more pluggable in the future. What other cool features should we be on the look out for that might be coming down the pipe?

So I think there's going to be like a really big push to code optimization and modification. I think there's like a lot that can be improved on. So it's not about building bigger tools. I think then it's really more focused on building better tools in the JavaScript community rather than adding more of them. So I guess this is making Babel like really good for this kind of stuff. I think there’s much more that you can do with modification that can have much larger gains than what's currently happening.

And as well as carry optimizations, so making it carry much more performance ahead of time and making trade offs that the browsers can't necessarily make. Like making certain decisions about how your code is executed more to make it more faster. So a lot of stuff like that. Yes, I think both of those are very powerful and haven’t really been looked at much in the JavaScript world.

Are there any plans to build Linting into it?

Yes, so I know [inaudible] tossing out between that actually. So it might appear like Linting is massively out of scope for a project like Babel or Babel just is a compiler. It shouldn't worry about linting or checking style.

Basically, it comes down to when you're doing code transformations, you need to be doing, use this

process, collect static analysis where you're basically checking the code, checking what's around it and inferring information just based on what the code looks like. So you're doing the core concept of linting in the first place. And so you're doing a lot of the linting work already. Most of the API's already there.

And so I'm not sure. I think there has to be really compelling reason for Babel to do it. I'm tossing out whether or not beta integration with something like ESLint would be a good idea or whether just like implanting Linting in core makes sense. I definitely think there's room for more and have investigation on that.

So I'm wondering when does ES2015 become finalized because it's currently in draft, isn't it?

Yes, that was finalized I think back in March. Yes, so basically everything in ES6 is now being standardized as official.

Okay, so then we're looking at ES2016 or ES7 or whatever we want to call it?

Yes, so as the name transitioned from ES6 to ES2015 have implies that it's sanctuary for more of a yearly approach to these specifications which means that yes every year there's going to be a new one released. The ES2016 is not going to be as dramatic as ES5 to ES2015 but there'll be much more incremental additions.

So do you think that these standards are actually going to be implemented by browsers? Because it seems like some of the things that have come along and I don't know if they're still in the spec or not but some things that have just come along, they seemed like a really good idea at the time. Because that was what was hot and that's what people were doing like observables. And then everybody was like, “Nah, who cares,” six months later.

Yes, so I actually think this is one of the big areas where transpilers play into this. Where it allows users and developers to use its features and investigate the practicality and whether or not they should actually be in this specification. So some people may be saying, “Oh, ES2015, this feature's crap,” pretty lack of hindsight in how it would be used or foresight in how it’d be used in the future and how it interacts with other language features.

But I think as more people start to use things earlier, we'll see much more feedback going into the committee. I think browsers are obligated to support this stuff. If for example Firefox implements something and Chrome doesn't, people are going to be just using - Firefox users will get it but it just won't work in Chrome. Those are the competitors.

[Coughing] Microsoft Edge, Safari, Android.

Yes, definitely. Microsoft Edge implanting basically like everything. So other browsers have to play catch up if they want to stay to be out, to be competitive. These browsers and vendors are involved in the committee process so if they have large objections to it then they'll raise them. If they don't raise the objections and then decide later, “Oh, we don't like this,” then that's kind of too late. You had your chance. Get over it, basically.

Well, I actually hope that if there is a major objection after the fact that they just don't do it because if a browser vendor decides, “You know what, that was a dumb idea and we're not going to implement it,” then at least you know that it's not going to work everywhere so you can't use it anyway.

[Chuckles] Well, then you'll just use the transpiler.

Well, maybe you will.

[Laughs] Most people will if you really want that feature, you transpile it. So yes, I think it's going to come to the point where just like most people are transpiling everything by default just because they don't want to trust the browser support. But then I think it will come to a time where like recently or like the last few years, companies have been dropping support for Internet Explorer 8, 9, so on and so forth.

Even big companies like Microsoft.

[Laughs] Yes, they're just dropping support for all the browsers. I think you'll have a baseline and your basic compiled on to that baseline. Or if you want to get really complicated and advanced or add a little more complexity to your system, you'll have different bundles for different browsers and serve them independently like using the latest version of Chrome. We know that other functions work in that. I'm going to serve you a different bundle that just has [inaudible] functions in it, just plain. They're not transpiled at all. I don't think the average…

So we're going to see like a patchy mod Babel, Babel?

Maybe. I don't know. I don't think most developers are going to be doing that. I think it's only going to be the tech giants almost that can justify having a system that complicated. I know there a lot of like big tech companies are already doing that. They ship different bundles to different browsers anyway, so adding in transpiler features so it's such a big deal. But I think small companies like learned developers, startups, I don’t think they're just like not going to bother and they'll just going to compile to that baseline. Maybe you can't justify the additional complexity like it just becomes like a really big mess.

So currently, do you see Babel as more for something like really experimental developers that want to play with new features or are you seeing it more as like this is a production tool that you should be using.

Yes, I definitely think it's - this answers as well the previous question of what separates Babel from Traceur. I think the marketing is mainly like a big thing. I'm seeing Babel as marketed since day one to be something production-ready that you can use in your applications with confidence. I guess that also ties back to the performance thing. If you’re using production, you care about performance and so optimizing for those used cases. I think Traceur was also being marketed as a bit more experimental whereas Babel has been pushed to be production-ready from day one.

Cool. And the end.

Is there anything we should have asked that we haven't?

Ah, TypeScripts. Oh, man.

Oh, yes and JSX.

Angular too.

Oh, yeah.

So, TypeScripts?

Yes, tell us your thoughts on TypeScript.

Yes, so TypeScripts. I shouldn't have said it like that.

The Babel team communicates a lot with Jonathan Turner. He's the head of TypeScript. And so in the future, I see more collaboration between the two projects, definitely since they’re not really in competition with each other. So TypeScript, the scope overlaps with Babel a bit but TypeScript is type checking and it just happens to have a transpiling component to it. And so you can use Babel as that transpiling component and use TypeScript for the type checking.

I hear a lot like Babel versus TypeScript like TypeScript is just ES6 with Types. It's not really. The difference between the way Babel would transpile as ES6 and the way TypeScript does, so TypeScript is much, much more lenient on how it transpiles it. They're a lot less spec compliant. So they've made trade-offs in that. They haven't been made in Babel for one reason or another.

How much of your personal time is spent on Babel right now? All of your time, really?

I guess that actually ties on how Babel is developed. I started out like in my free time and then basically ever since I started it, it’s been like that. Just like just spend the afternoons or weekends working on it. But recently I've joined Facebook where I'll be working partly or mostly to develop and maintain Babel which gives me a lot more focus and time to do this kind of stuff.

Still basically my present time is consumed by Babel shifting that where I'll be able to work on other things in my spare time. Other projects like I don't really have time for other open source projects since I'm spending all my time maintaining Babel. And so I'm really excited for that. And I'm really excited to be able to spend more time making Babel as stable as possible and as powerful as possible.

Is there any chance we'll see you joining TC39?

I have no idea.

Well, you got my vote.

Thanks.

Before we get to picks, I want to take some time to thank our silver sponsors.

[This episode is brought to you by Code School. Code School offers interactive online courses in Ruby, JavaScript, HTML, CSS and iOS. Their courses are fun and interesting and include exercises for the student. To level up your development skills, go to

JavascriptJabber.com/CodeSchool.

All right. Joe, do you want to start us off with picks.

You betcha. I have one main pick today. And that is that I'm going to be doing some training on Angular for a company called Primitive.io. It’s like in a month. It's a two-day virtual classroom training scenario like six hours each day for a couple of days. Now, it’s like limited class size. I'm actually really excited being able to teach a class and being able to interact with the students rather than just speaking in front of a ton of people. So I'm pretty excited about it. Good way of leveling up one's skills. You can register at Primitive.io. I think they're offering a heavily discounted rate right now for the class. So that's my main pick.

My second pick is going to be the book Armada which I feel weird picking it because I've been reading it. I'm about 20% of the read-through and I'm completely bored. But I know that if I power through that I will like it. I don’t know if any of you guys loved Ready Player One. I've got it in front of the room. I'm really disappointed with how he started out the book. The first 20% is really slow. But I believe in the author because Ready Player One was so awesome. So I'm going to pick it anyway.

All right. AJ, you have some picks for us?

I do. So I will pick just two things today. One, I have been listening to Dale Carnegie's How to Win Friends & Influence People and if you know me you know that it will probably have zero effect because when you multiply anything by zero you still get zero.

I was about to ask if you've been reading that because I felt, you know, pretty friendly around you. [Laughter]

And influenced.

Yes, I felt influenced.

Oh, that's good or bad or what it is. Anyway, so I'm going to pick that. I think it's in my top five of books like self-help type books that a person should read along with Innovator's Solution and Influencer: The Power to Change Anything. I don't know what other two I would put in there. Maybe color code for fun, just for fun. It's just pop psychology.

Anyway and then [makes a trumpet sound] in case you haven't heard, which you haven't heard, there's a new podcast in town, Web Security Warriors. If we're lucky, that should go out on DevChat.TV around the same time as this episode I think, maybe.

I might be able to confirm that. Yes.

So check that out. I think we still need to put an intro and outro sound clip to it and then the first episode will be ready to go.

That's my picks for today.

Yes, so if you want to learn more about Web Security, check out Web Security Warriors. If you don't think you need to learn more about Web Security then definitely check out Web Security Warriors. Aimee, do you have some picks for us?

I do. Mine is another plug/pick. So I think it was two weeks ago, I picked Nodevember and that's going to be my pick again this week because it's back in National where I went to my big camp, absolutely love National. So if you're looking for a conference to attend in November about Node in JavaScript, how about check out Nodevember. And that's it for me.

All right. Dave, have we heard your picks yet?

No, you haven't but you will if you want to.

Probably even if we don't want to.

Yes, you're going to hear them one way or another. I guess you could press the plus 15 seconds button on your phone right now a couple of times and you'll probably be happier. Anyway, no, you won't be happier. You'll be very sad. So here's what I've got for you today.

I’d like to pick up an oldie but a goodie called The Hitchhiker's Guide to the Galaxy, one of my favorite books of all time. I picked it up again and started reading it and just remembered why I love Douglas Adams so much. Huge fan of The Hitchhiker's Guide to the Galaxy.

And then the second pick is actually a two-part pick. I would like to pick Yellowstone National Park which if you haven't been to Yellowstone National Park and you can, you owe it to yourself to check it out. I went this weekend with my family. What an incredible weird place, full of cool, just crazy, cool stuff. You should definitely check it out.

I can't think of a better time than when you're going to be in town for React Rally at the end of August here and about when this podcast comes out. It will be three weeks away. You owe it to yourself to get an extra day, drive four and a half hours up to Yellowstone and check out that Park while you're here for React Rally. Those are my picks.

Very cool. I've got a couple of picks. Just really quickly as many of you know I have launched Rails Clips and I did a Kickstarter campaign to get it going. I promised backers who backed to the certain level that I would do them a favor. So my two picks this week are favors.

The first one is if you're interested in learning Angular and you live in Switzerland, there is a course out there taught by Daniel Egger. And I'm sure I said that not German enough. Anyway, I'll put a link at the show notes. Definitely go check it out if you're looking to learn Angular.

The other one is long time follower. He actually did interviews of all the Ruby Rogues several years ago. His name's Thom Parkin and he's looking for job. So he's been programming, he said since before the original Star Wars movies which means that he's been programming longer than I've been breathing. He's been doing DOD contracts and he's looking for something else. So if you know of some work and you're looking out for that, go ahead and check the show notes. He's Parkin, that's @parkint on twitter. So, yes, let him know and yes, those are my two picks this week.

Sebastian, what are your picks?

Ah, so I've got two. So, the novel The Martian by Andy Weir.

So good.

Yes, awesome. I barely ever read but I started reading it and I've read it in one sitting. It's being made into a movie but you should definitely read the book.

And my second pick was I tried Five Guys for the first time yesterday and it was amazing.

Five Guys.

Love those burgers. [Laughter]

Made your life better, didn't it?

Definitely.

Where? Which location?

London.

Oh, they're expanding.

Yes, they've actually got quite a few locations in the UK actually.

Oh, nice. Just my humble opinion: best burgers on Earth, even better than the ones I make.

Yes. Good stuff. All right. Well, thanks for coming, Sebastian. It was fun to talk about ES6/2015 whatever it is and Babel.

Thanks for having me.

All right. We'll catch you all later.