 Hi, my name is Sebastian McKenzie. I just moved here around nearly two months ago. I work for a company called Cloudflare on web content optimization, so measuring website performance and optimizing code and stuff like that. So I'm here to talk to you about Babel. Any of you use Babel with Ember CLI? Have any of you disabled Babel after you've created a new Ember CLI application? Yeah, be honest? Well, you'll find out. So Babel is a JavaScript transformer, a JavaScript compiler. So you put JavaScript in and you get JavaScript out. Kind of the popular use case for it is as an ES6 compiler, but it can do a whole lot of other stuff. So there's a plug-in architecture that allows you to hook into this pipeline that allows you to transform JavaScript. So yeah, transpilation is the common use case. It's how Babel law started out, but it's kind of slowly becoming more generic. So how does this work? Hopefully, this will give you more context if you actually don't know what it is. So you've got some source code that you want to transform. You want to do something with. And you need a structure to represent this code. And you represent it with an AST, Sensory Abstract Syntax Tree, where each component of your source code is basically an object or node on this tree and all the different properties of your code are represented in something that can be inspected. An easy way to visualize this data structure is via tree. It's the T and AST. And so here you've just got your, it's the previous source code where you just got a program and a variable declaration and a whole bunch of nodes coming off that. And so now that you've got some context of what an AST is, these are kind of the three parts of Babel. You turn the code into an AST, then you manipulate that AST and then you get, and then you transform it so you infer stuff about what the code actually does based on some of the properties of it. So you've got a class, then you know that's a class and you can compile it to previous old code that works in older browsers. And then when you transform it, then you pass back onto the code generator, which turns out AST, the manipulated AST structure back into code that you can execute. And so this is kind of, if each part was proportional, most of Babel's in the transformer or the transformation layer. And this is important since, so this is traversal where you've got an AST and you need to visit it, you need to manipulate it in some way. So traversal is so you would go to each node and run the visitor with them, visit it and run some code over it. And then you do this for each element in the tree, so going down. And then at any time when you're visiting this, you can add new nodes or remove them. And so this can be kind of tricky. So if you're visiting some nodes or some part of your code and you replace or remove parts of it, then sometimes it may result in invalid code. And Babel's kind of smart in the way that it transforms it where it's contextual so it understands JavaScript semantics and kind of what JavaScript, what your code actually does. And this leads to kind of some smart transformations. So something like this. So here this is an array destructuring, it's a new feature in ES6. So here it would call calculate coordinates and then the zero and one index would be assigned to the X and Y variable. And so this would be desugared into something like this where it says it just executes and then just assigns the zero and first index. So this is an array destructuring assignment in a statement position. So what if you've got it in an expressing position like this? Well, if you run that exact same transformer over it, you would get this code, which is obviously invalid. And so this means that you then have to basically special case each instance where a certain syntactic construct might appear. And so this leads to really tedious transformers where the code is like very verbose and you need to basically replicate each possible position where that thing could appear in. So instead Babel kind of shifts that checking logic into the core where that exact same transformer would result in this code. So it can infer you're replacing an expression with a list of statements and then explodes it, retaining all the original kind of semantics and what it actually means. So this is also handy for removal. So you've got just a binary expression where you're plusing left and right-hand side together. And if you wanted to remove the right-hand side, then you would typically end up with something like this, which is also invalid. But since it's aware of what JavaScript means, it's knows that you're replacing one side of this binary expression and it will result in invalid code, it just turns it into the left-hand side. So figured I'll just demo and go through like some of the possible ways and kind of some of the use cases of Babel. So how many of you use something like Uglify.js to minify your code? Yep, yeah, it's basically the more common one. Eventually in the future, I kind of hope for minification plugins to be built on Babel. So the goal of Babel now is to kind of be a generic transformation thing. So it's just a JavaScript compiler that stuff can be built on top of it. So stuff like minifiers or module bundlers and stuff like that. So if JavaScript's becoming a really increasingly evolving language, new features are being added to it. And if a new feature is added, you have to wait for all the different kind of parts of your stack to like the different tools that you use that modify or link your JavaScript. They need to be updated to support this. But if it's all built on a common platform, then it means that it can all work as long as the core thing, which is Babel, supports it. And so one of the things I've been playing around recently is dead code elimination. So if you just have something like this normal function. So here you see that it's actually compiled it but it's determined that fruit isn't actually used so you can get rid of it. But if you actually just reference it, then it determines that you only actually use it once and it inlines it. But if you were to use it twice, then it would just keep it as is. So this is kind of something that Aglify already does. But the way that this is kind of written it, it's an extremely simple plugin that could eventually like push that to MPM that you could then include in your stack relatively easily. So it also like really simply just does stuff like if you just have another call after that or something, it determines that that code is then going to be reached. This is like you may be saying like why is this used for like I don't write code that doesn't actually get used or executed. But Babel also has another transformer called constant folding. Aglify also does this to some extent but it's kind of not as smart with it. So for example, it allows the compiler to statically evaluate expressions that it can determine a constant. So if you were to just do, then it can determine oh hey, you've got foo and bar assigned or declared in scope and it can infer that that will always be three. So it executes it there. So this could lead to stuff like just smarter minifying where even though this may be fairly simple and you won't, it's not really optimizing the code, it's more minifying it so it's smaller to send across the wire. And so then you can like, it can support like a whole array of like different kind of expressions. So basically anything that just includes immutable kind of data it can kind of handle in a really smart way. So these are some of the ways in which kind of having a platform for this where there's a lot of like smarts and stuff in the core can lead to kind of some really complicated stuff done very easily. And another thing that I've been working on recently would be, let's get the code up. So we have this set of code. So something that you may want to do that leads to kind of more smart and sophisticated transpilation or compilation of your code would be type inference. So knowing the types of certain variables can lead to stuff like just smarter minification. So if you can infer that something is of a certain type then you can change the way in which you compile or change that. So this code would be if you, so internally Babel's representation of it would be something like this. So here we've got the possible values or types that this expression would currently be in. So it can infer that in this case that foo can be string on array. And this case can actually determine that it's just normally, it can only be a string since it's assigned right before it. But it's kind of like it'll get there eventually. It's very limited in kind of some of the stuff you can do. But in the future, once it's more solidified and it can do stuff like inferring the types between files, this will allow for much smarter minification and transpilation. And Ember CLI is being partly rewritten and most of the JavaScript transformation stuff is being moved into Babel plugins. So they could potentially utilize some of this stuff to make your Ember applications compile into smarter JavaScript, faster JavaScript or a smaller JavaScript. And yeah, so there's kind of a lot of potential for stuff like this, especially just a smart thing that's aware of what your code does. That's very generic. So another thing as well is that there's a, so have any of you, do any of you use JS hint? Yep, I don't have used decorators as well as your code. Sort of, yep. So Ember is slowly moving to this. Yehuda Katz is currently championing a proposal for JavaScript where they implement these concept called decorators that replaces a lot of the object model of Ember to use native classes. And so since it's very experimental, if you try to link your code that uses decorators, it's just not gonna work with JS hint. But if there's another lintel called airslint that has a Babel plugin that allows you to link any of your code that's Babel compliant with airslint, it uses the Babel password to pass your code. And it can, yeah, so as long as the tool supports Babel, it can kind of support anything Babel does, which means, yeah, less work for everybody. And if JavaScript's moving to this increasingly evolving language, then kind of there needs to be something that keeps up with that evolution. Yeah, so that's kind of it. Does anyone have any questions? If they're still confused on what Babel is, I didn't do such a good job explaining it. I think it's a good report. Thank you. Maybe do you want to say a little bit about how you got started? How you got involved with it or was that a little bit rather history-like? So it started around early October last year. Yeah, it started as a project called 65. I just wanted to learn about compilers and parses, kind of how that works. I realized that was kind of a large gap, in my knowledge that I didn't understand. And then slowly it's kind of evolved over time to support the entire ES6 standard so you can compile it to just code it runs in any browser right now. And so yeah, it's just slowly evolved into something where kind of built up this ES6 transformation layer and then realized there's kind of a lot more potential for someone like this where other people can utilize some of these parts to do some cool stuff. Yep. The state of Babylon's got to, it's starting to look almost like LLVM and it's kind of the level it operates at, the things that you can build on top of it. Is that something you've been inspired by and looked into? Yeah, so it's also like, I kind of see this sort of being like GCC for JavaScript almost, so you can like apply specific optimizations on your code. I know you may think like all browsers don't already like optimize my code, aren't they like extremely good at that? Well, browsers can't really be the lenient on your code like if you say you want to do something that has to do that, even if, so if you can compile and transform it in a way that gives the exact same result, just it does it in a different way, then it'll be like much faster. So only you can kind of tell the browser engine to be more lenient, like, yeah, so that's kind of where I see that going where, yeah, that answers your question. So yeah, yeah, yeah. Yep. So, you who has currently got a RFC of them for the release process of Ember? And in that he talks about spelt build to Ember where you can strip out features that you're not going to use. Would the dead code elimination sort of negate the need for that because you could run it against your Ember app in the library file and it could just strip away all the parts of Ember which you don't actually use? Yeah, yeah, that's potentially something to be done. So like ES6 is very declarative in what it does. So if you're using like ES6 modules or exports, then like it knows what you need since you've explicitly stated the parts that you're importing. And so to do that kind of stuff, Babel kind of needs to be aware of the entire dependency graph. And I've been talking with Stefan or Stefano, everything that's his name. The guy who created Ember CLI in how to kind of incorporate more of what Ember CLI knows about your application into the Babel integration, which yeah, will lead to kind of smaller code since if it hasn't access to your entire code base then it can determine what's actually going to be used or not. So I guess, yeah, I was in the Ember world. So I've written the line of Ember in my life. So yeah, so that's very potentially something that could negate that. Question about how plugins work because when you write a Babel plugin, basically it's like you were piping the AST from the previous step to each plugin. So you only convert at the end to regard code? Yeah, so if I were to... So at the moment, basically plugins exist in this layer. They might potentially be able to provide custom syntax. So you could have a plugin that adds macros to your code, I guess, just kind of some language experimentation features. But yeah, it can either be run, yeah, so it exists in this layer where it passes the AST and then gives the AST to a plugin and then the plugin does its thing and then it passes the AST back to the code generator. So I remember hearing, I referenced earlier this year or last year about the merger. So six to five and ES next. Yeah. And were there other projects involved? You kind of all plugged together behind six to five and then... The merger was more with it's like ES next dying. Yes. Six to five at the time being the thing. Yes, that's kind of one of the only things that kind of came from it. Another project that Babu uses for generators and async functions is Regenerator, which is a Facebook project. And so, yeah, that's used heavily for some of these features. Oh, so that's another question then. The bits that have runtime components. Yeah. What's the story with that at the moment? So I haven't used them enough to really understand if you get to that. Yep. So the only part that requires a runtime component is async functions and generator functions because they can't be easily compiled to ES five. All the other features, if it needs by some extra runtime code, then it inserts it into little helpers that can go at the top of the, that hoisted to the top of the file or there's like a couple of different ways in which these helpers can be inserted. There's a external helpers global script that you can just include a script and then enable a flag on Babu. And then when it has to output a helper, it will reference the global. There's another one where it can import the helpers and then reference it, the helpers that exists in another module. And so there's a lot of ways to kind of get around this. But by default, Babu will just include small helpers in your code. Is that it? I have more questions. What's your background? Nothing. Nothing. Yeah. So is Babu the form of the artificial node? Sort of. No, it can determine what it understands JavaScript. That's good. That's what I'm talking about, yeah. That's more than some of us can say, yeah. Okay, all right. Thank you so much. Is there one more there? Oh, yeah. Yeah, you can go over there. Oh, yeah. So how do you communicate? You need to do JavaScript elements. So in some ways, does this fit in my development pipeline? What sort of basic tasks do I use it for? So... So what do you use it for? So have you used CSS before? So have you used the CSS preprocessor? Like less or sass? This is kind of the same thing with JavaScript. Where you write your JavaScript and then you pass it through this and it gives you JavaScript back out. Has there like the exact similar advantages to using the CSS preprocessor? Oh, yep. So how it works like a coffee script that's still going to roll... Sorry? It's still going to roll with some place coffee script. Sort of. So a lot of the kind of features that a coffee script provides are already kind of present in ES6. And so that's kind of where the community is going to be going towards. There's a questionable future for coffee script where a lot of what it provides is already in ES6. And since there's kind of like this syntax of certain minimal, there's a lot where you can't really add a whole lot to it and still keep it simple. Like stuff like the classes that coffee script has kind of some of the ways in which they work are very different to ES6 classes, so they're not really compatible. And how coffee script is going to kind of keep up with that, I'm not sure, but yeah. So coffee script is more of a one-to-one mapping to JavaScript, almost, where this is kind of a bit more, it infers a lot more about your code and kind of transforms it on a much higher level, almost. Yeah, basically, yeah. That certainly seems to be where the community's headed. Yeah, well. In the number of, like, a lot of the frameworks are going that way. Yeah, well, it's kind of the standard is going to be like the future for us. And it's kind of like the only real reason to use like coffee script almost at this stage is if you just hate like semicolons or parentheses. Which is like perfectly valid, like, if you don't like those and like whatever, continue using coffee script. Are there any ES6 features that can't be rewritten in JavaScript here in Mexico today? Yeah, so one of them, it's like all of the syntax forms can basically be compiled into ES5, or code that can run in browser spawns. I mean, it's when you get into stuff like proxies, ES6 proxies where you can intercept stuff like if it allows kind of a high level, allows you to kind of construct these exotic objects that like if you were to get a property on that, you could intercept a property access to it no matter what property it was accessing. So typically you would set a getter, but what if it accesses a property that you haven't set a getter for? Proxies would allow you to intercept kind of all that kind of stuff. And in order to do that, it would have to be extremely intrusive in how it rewrites your code. So it would, if you were to access like just any property on an object, it would have to add in code that checks to see if that object is a proxy or not. And that would lead to like generally verbose code, with long code and it would be really bad for performance. So you can basically like compile anything. Since you have access to the code, it's just whether or not you can practically do it. It's kind of a different question. But some of the stuff like the type inference that I've been looking into will allow potentially flat stuff to be compiled. I mean, it's more complicated features added to the language. It kind of means that the compiler needs to be smarter in how it understands the code. Thanks, Stu. Another question. Do you think there is any chance of things like TypeScript or Flow being rewritten as Babel plugins? So at the moment Flow is just like a type checker. Yes. Just a static analysis engine. So it's kind of a separate thing. But TypeScript, like, so you use Flow with someone like Babel. That's kind of, so Babel supports Flow type annotations and it strips them. So they kind of use those hand in hand. So TypeScript is another thing where it could potentially be written as a Babel plugin where it understands the TypeScript syntax and does type checking through the Babel plugin. So yeah, you could kind of do similar kind of language experiments with TypeScript. It's just where you get into whether or not it's a performant or not to do through JavaScript. So Flow isn't written in JavaScript. It's written in OCaml. And it's a separate demon that you'll have running on your computer. So the reason that it's kind of partly why it's done that is because it needs to be extremely performant in how it does it and TypeScript can't infer as much information about your codes and so it can't be as quick almost. And so yeah, you're kind of also limited to like JavaScript and the runtime. Yep. Embercon earlier in the year, Matthew Beal gave a talk about the future of JavaScript and kind of posed a vision where as new bits of syntax are proposed in the working groups they will likely appear as Babel plugins in tandem and you've been kind of seeing yourself getting more involved in the standards process through that. Are you happy, sir? Well, Babel is kind of already like almost there where it's like fact. So there was like a month or so ago this new ES7 proposal for function by and syntax was added to Babel and people have been experimenting with it and providing feedback to the proposal author. And so yeah, so it provides early, more early feedback to proposal authors, which means that if something gets in the JavaScript language as a standard then it's going to be have been thoroughly tested beforehand through a compiler like this. So I think like in the future, yeah, it's going to have kind of a big say in what's standardized. Are you personally kind of, is that something you're even interested in, sort of role in the standards? Yeah, I'm definitely interested in that kind of role in standards, as well as like helping other people that are invested in the standards or like people who are writing these proposals and allowing them to get feedback on their proposals inside of it. All right, thank you very much.