 going to talk about ES6 today. Some people like to call it ES2015. I still call it ES6, so I hope that doesn't offend anyone in the room. If you're on TC39, you might be upset at me, but I apologize in advance for that. All right, so features by testing. We are going to spend the first part of the talk doing a quick high level overview of several of the ES6 features that you should be aware of. There are many of these talks out there, so I'm not trying to duplicate necessarily all the other great talks that have been given on ES6 at lots of conferences and lots of blogs and books and things like that. But I'm going to take a particular bent on this, which is I'm going to show you before and after shots of code that's been beaten with the ES6 stick. And we can see the effect that it has on our code. And generally, it's a good effect, but there are places where you can do some real damage. So that's our goal with the first half. The second half, we'll turn our attention to how we can properly decide how these features show up and whether we're using Transpillation and how we're using Transpillation. So that's the second part of the talk. Before I get into this talk, however, every conference talk now that I do, I am starting off with this particular declaration. So I think that it is clear and obvious that we have a diversity issue in our developer industry, and especially in the web developer industry. And there are people, every time I do this, there are people that come up to me and argue with me, and the fact that they argue is proof in and of itself that there is this problem when you fight back so hard against this. So I feel like we just need to open our eyes. And I do not have any solutions to the fact that we're not an inclusive enough industry. I don't have any of those answers, but I do know that we're not talking about it enough, and we're not using, we're not portraying enough awareness of these issues. So I started out all of my talks by simply declaring an awareness of my own privileges. This is not to project on anyone in this room for you to say that he's trying to criticize me or say that was or was not a privilege for me. That is your own decision, but I would encourage and challenge you to think about these same things the way that I've chosen to think about them for myself. So privilege awareness. First, obviously, I'm a male. I have both a son and a daughter, and it pains me to think that they may not have an equal path growing up if they both decided to get into development. That's completely unacceptable. And I'm already teaching both of them. They're both young, but I'm already teaching both of them to appreciate computers and I want both of them to come into an industry that does not care, that does not second guess. I don't want my daughter to somehow feel that she's been second guessed or assume that she didn't have quite the right qualifications for something. So it's unacceptable that that is a privilege of mine that helped me get where I was because nobody ever had to second guess whether or not I was up to the task or qualified. In fact, many times people assumed too much of me. I'm white. That's pretty much as obvious. But I never got second guess based upon what neighborhood I grew up in or what part of the city or part of the country that I grew up in or anything like that. I did not get second guess on those things. And there are people that have achieved as much or more than me that have had to work much harder to get to those same places. And it's completely unacceptable and not fair. I'm also educated and that is a privilege. It's a privilege that I grew up in a place where it was assumed that I would go to college and it was assumed that I would get scholarships and it was assumed that I would be able to qualify for loans and student aid and things like that. It was assumed that I would go on to further education. And it's unacceptable that there are so many people in this country and so many people in this world that that is not only not assumed but it's not even possible for them. I'm heterosexual and I'm thankful that in this country this is becoming less and less of a privilege. It's great to see that nobody is going to second guess my own personal decisions or anybody else's own personal decisions. But we've got a long way to go still. So that was a privilege of mine. I never had to worry about hiding some part of my true identity. Being American of course. And also being employed. I've had some privilege that I haven't had to struggle because I've been able to stay gainfully employed for the majority of my career. These are all things that personally helped me get to where I'm at. And I'm simply starting a conversation by saying I want to be aware of those things and I would challenge you to be more aware of those to look to your left and your right not only here but when you're at work when you're around other people look to your left and your right and ask where is the privilege unequal and what is something that you might be able to do to level that playing field. So that's how we'll start. Now a couple quick things about myself. I've written a series of books about JavaScript called you don't know JS. The entire six book 1100 page series is available for free online at you don't know JS.com. It's up on it's up on GitHub so you can read it. Most importantly, the sixth and final book of that series is called ES six and beyond. So I dive into ES six and tell a narrative arc about where JavaScript is headed in the future beyond ES six. So a lot of the things that we talk about today are covered very much in depth in that book. I'd encourage you to check those out. They're also professionally published by O'Reilly. So if you like the books, of course, I'd appreciate it if you bought copies of them. I'm also recently employed as head of curriculum for maker square. Prior to that I spent about four years as a corporate trainer. And I'm still doing some of that under the umbrella of maker square but his head of curriculum. We're a developer and engineer training school with locations in Austin, San Francisco and Los Angeles and we're going to be expanding eastward my guess would be soon. But if you have ever thought about developer schools or had questions about them or maybe serious doubts about them and what they mean to the employment industry or just have some thoughts you want to share. I'd love for you to come up and ask me about that. I'd love to talk about maker square or if you know somebody that's interested in getting up to speed on development, we'd love to talk to them. So please come up and reach me about that. All right, so let's get into this talk. ES6 or ES2015. There's an awful lot of features that make up ES6, ES2015. We're not going to cover all of them but just as a quick smattering, here's a comprehensive list of all the topics and by the way, you'll find those as section headers in my book because there was a lot to cover. I thought it would be a quick little 50 page guide and it turned out to be a 250 page book and there are much longer books than mine even. So there's a lot that ES6 did for the language. It was a long time coming, five years in the making, so there was a lot to it but that doesn't mean that all of it was great but there's certainly a lot of amazing things about it. So we want to look first, we'll start with maybe some hype stuff that is not so great and then we'll look at some stuff that is great. So first starting off, I'm not going to actually beat up on JavaScript too much. Sometimes I give up, stand up and get talks and then people come up to me and say, do you hate JavaScript? And actually it's the opposite. I love JavaScript but with that love comes a particular criticism of the things that I think could be better. So this is one of those things that I think is the least exciting, the least interesting, the most problem-ridden in JavaScript coming with ES6 and this might surprise or frustrate a lot of you because if you've gotten on the ES6 train, this is probably the first thing that you got excited about and that's the arrow function. So starting out just looking at the simple example, this is the example that almost everybody uses, well we got these short little inline lambda functions and we're passing them as a callback to a map utility for example. And it seems very frustrating to a lot of developers, I'm not sure why, but writing out the word function seems very onerous and writing out the word return seems very onerous. So we invented this newer shorter syntax which seems or purports to make things so much cleaner. So now we have this fat arrow syntax and if you're having trouble deciphering that, that's because you just haven't seen it before. If you've been in a language that has them, it probably jumps right out at you, but I find in my job as teaching developers that the first time somebody sees a syntax it looks a little weird. What's going on? Well the first val is the parameter list and there's a special exception that if the parameter list has one and only one parameter then you don't need parentheses and then the fat arrow indicates that this is one of those functions and the next expression that shows up, if it's just an expression without any curly braces it's assumed that you meant to return the result of that expression. But if you need to do something more complicated you're going to have to wrap things in curly braces and then you're going to need a return and oh and by the way if you have two or more parameters it needs a parentheses and if you have zero parameters it needs a parentheses and if any of those parameters have any of the special ES6 things like spread to them or destructuring or any of that stuff, oh by the way now also you need parentheses. So there actually turns out to be dozens of different variations on this syntax. So I think we do a disservice and I mean we, the people that educate the rest of the community, we do a disservice because we show you the nice happy path and we never talk about the potential downfalls of you just simply saying I'm going to apply this arrow function to everything I do and that's what I see people doing. There is one very specific set of circumstances that this was designed for and it's designed when you are dealing with a this keyword in lexical situations and you would otherwise need to do that crap like var self equals this or dot bind that's what these were designed for. So if you have that in your code be my guess go use arrow functions but in all the other places there's actually quite a bit of quite a few caveats to it. For example is a function maybe not now but is it ever going to need a this or a super because if you make it an arrow function you may be setting yourself a landmine later. Is it ever going to need a lexical name because arrow functions are anonymous and they can't self-reference for recursion or event unbinding. Is it ever going to need more than one statement in it because right now it only needs one but when you go back and refactor you're going to have to remember both the curly braces and the return statement. You're setting up landmines potentially if you're not asking these questions. Is the return value from an arrow function ever going to have side effects. There are many places where we're just passing these arrow functions and not worrying about the return value but there are times when a return value has side effects for example to a filter function. What you return back matters. So we have to be more careful about the way we use arrow functions and you can't just simply do a find and replace. And are all those syntax variances not just the happy path but are all the different variances really readable and obvious. Or are we perhaps setting up ourselves for harder to read code because there's so many different ways that an arrow expresses itself. For example I have this little chart. This is a decision tree chart for how to decide if you need arrow functions and I'm not going to go through the whole thing but it is in the book if you're interested. It's more complex than just hey arrow functions are awesome. So I would say that there's this is a good feature but as a specific usage and as with all things you should use the tool responsibly not just simply blindly. All right so that was the hype train. I won't beat up on that part of JavaScript anymore but let's look at some other stuff. So I'm going to give, we're going to have some audience participation today because the topic can be kind of dry and boring like JavaScript syntax. So audience participation and upcoming slides I'm going to show these before and after slides and I'm going to label these slides with either a frowny face or a cheering or whatever. So when you see this when you see the frowny face I want everybody in the audience to say boo so let's practice real quick. When you see the frowny face what are you supposed to do? There you go and I'm not going to feel bad that you're not booing me you're booing the code and that's totally okay. So then we can see this and I want everybody to say meh. Just a real short you got to do it like meh. Yeah there you go. Alright and then if you see this everybody goes yeah let's practice one more time. This is going to be fun alright so let's jump in. The substance of ES6. The fun stuff. Alright so the old way of dealing with arrays and putting them together and sticking them together use this funky syntax with the concat method and we had to put them in weird places and this is definitely the new way embraces a dot dot dot operator which in this context we're going to call the spread operator and you'll notice here when I put dot dot a in front of a it's spreading out the contents of that array in that location and then I'm spreading out the contents of the sliced B. So we have an operator to specifically do that we don't need to worry about all that concat and weirdness and stuff so we can use arrays and spread them out in locations where they need and we say awesome. Alright next using that spread also works in context like with function arguments. The old crappy way of needing to pass an array of arguments into a function was to call apply and when it was a not this aware function we just stuck that ugly null on there because who knows what we're supposed to actually put. So that's the old and busted way. And the new way we can just simply use the spread operator to spread out an array in an argument position so it works inside of arrays it works inside a function argument. We can talk about some questions afterwards but I'm just giving you a quick overview of these sorts of things so this is a sometimes called a splat operator in other places in JavaScript we can call it the spread operator because it's spreading out an array value so any place where a set a series of values could be placed you can spread out an array and actually can spread out any iterator but that's getting a little ahead of ourselves. Alright so moving on. So here we're spreading out an array which is great but in the function I have this variable called C where I'm actually asking for all the other parameters besides the first two named ones I have the A and the B that are named but I want C to be an array of the rest of them and to do that I do this old school ugly dot call with arguments thing and slice off the first two and whatever and that is definitely the new way the new hotness we can simply use what's now called it's the same operator but in this context instead of spreading things out it's gathering them together so I call it the gather operator a lot of people call it the rest operator but I'm gathering everything else up into a variable a parameter called C so it's doing a lot of that work for us now that you should start to see a common thread in these examples and I'm choosing these examples on purpose because the real important narrative of ES6 is that its goal was to simplify existing idioms so that code is more understandable that is not the same thing as saying I want to type less it is to simplify the understandability of code simply removing characters from your code is not necessarily making it more readable and there are a lot of people that think that's the case it's definitely not the case but here I want you to see that there are lots of ways that we can use ES6 features to simplify our code and that is the most important thing because here's a little hint code is not for the computer did you know that did you know that your source code is actually just a set of suggestions to the JavaScript engine it looks at your code it's like yeah see what you want to do I'm going to do it in an entirely different way and there's an infinite number of programs that you could write that would produce the same effect so if that's true what is code for is for communication it is first and foremost a means of communication with other human beings other developers on your team and even your future self when you come back three to six months from now and look at some code is your code telling a story is it teaching itself when I go back to refactor code that's what I worry about I look at some code and I say I had to work too hard to understand that what I need to refactor is not for performance not to add a new feature I need to refactor to make the code more understandable that's really one of the best narratives about what ES6 provides all right moving on default parameters you see I'm using the existing features bring those along but now what we what if we wanted to have a and b have some default values to them the old school way was to ask if a was passed in as undefined and then set it to the default value three and b to the default value four otherwise use those values so that sucks the new ways to simply declaratively say what our default values are for the parameter see they're in the function signature we can say a defaults to three and b defaults to four and it does that work for us exactly thank you alright what about pulling values out of function so you have a function that's returning an object or maybe you're just getting a JSON object back from some Ajax call or something if you want to separate out those variables those properties from the object into variables and this goes for objects or for arrays you usually have to end up creating this temporary variable to pull things off so temp is the object and then a is the a property and so forth and that's definitely right you guys are getting lazy that's alright I'll let you off the hook alright so that's definitely a boo this new feature is called destructuring it's kind of a little bit like pattern matching if you're a language won't from some of the language that a pattern matching it's a way to declare what you expect the value to look like the shape and the structure of the object that you look like and to to match those values into assignments so here's the destructuring we've declared an object on the left-hand side of the equals which might look a little strange that's why it's new syntax but I'm saying I expect an object that has somewhere on it in a property and I expect an object where somewhere on it of B in a C property and by the way that C property is an array and now I want so what I'm declaring is I'm declaring variables like ABCD and E and I'm assigning those to the values that I pull out of that object now this looks nice except the problem is that a lot of people are demonstrating destructuring kind of like they write their pearl which is try to put as much crap on one line as possible this is a terrible idea here's a little hint for you white space and indentation are free what is this it's better but this is so much better because we use the free white space and indentation to actually show the structure that we're expecting and you can imagine if you were dealing with a more complex JSON object structure for example it would be much more declarative in your code the structure that you're expecting and by the way it's pattern matching in the sense that we don't have to account for everything you only account for the things you care about so if you leave out a property it just gets ignored if you add a property that's not there it just gracefully gets assigned and defined okay so that's good what about renaming variables because what if I don't want to be the same variable name the old-school way is to actually have a temporary variable like var x equals b and and what if I wanted to default value in one of those assignments if it was missing well we have to do a crappy type of thing so this is definitely the but we can actually use all those same tricks here we can rename b to x and we can give f a default value right inside of the destructuring syntax so exactly thank you finally I didn't even have to prompt that time see we can actually declare it's a declarative form that makes code easier to understand alright so one of the one of my favorite ways of using this I run into this quite a lot where I have an object that represents some defaults and it's not just a flat object it's got a bunch of nested structure to it and these are all some defaults for some you know utility that I've built and then somebody passes in a config object which is not fully populated but has some stuff that we want to override and you've probably seen libraries that all kinds of crazy utilities like extend and inherits and all the kinds of things to sort of deal with this and they all have slightly different ways of dealing what if it's missing or what if it's too much you know there it's repeated or whatever well ES6 gives us kind of an interesting way to put put two properties together so that's the old school right and this which looks hard until I zoom in on it this is what I call the destructuring and restructuring pattern so let me zoom in here first what I have is I'm destructuring this is a let declaration so I'm pulling out all of these properties into actual variables and by the way I stuck it inside of a curly brace block with let so that they are polluting into my enclosing scope so that's good so I'm destructuring them all out and by the way taking advantage of the default value behavior that we have so I don't have to do any of that logic myself and then I'm restructuring it back into what I want I'm using what's called concise properties here because if the property name is the same as the variable we don't need to specify it twice so I'm restructuring the object back with all of those defaults mixed in with the stuff that was already being set manually I love this pattern I'm already using this quite a bit in my code alright let's take a step into some asynchronous patterns this deserves way more attention than I have time to give here but asynchronous patterns like promises and generators here's the old-school callbacks way of doing one Ajax request and then another and then a query a sequel query it's ugly we've got all this callback being nested but it's actually there's a lot more problems to callbacks like they're not trustable and so there's inversion of control and other things like that they're also not linearly reasonable so can promises fix things this is the ugly boo and then if we promise a five these functions we could make a promise a five version and you can do this and a lot of people do but that gets a little bit tedious to promise a file of your functions so there's libraries out there that let you wrap or lift these functions one of those libraries is one that I've written it's called a sequence it's the word async plus the word sequence mush together mostly because there weren't any other good names I'm not here to sell you a sequence but I'm just showing you that this and many other libraries out there have these utilities that make the promise of my versions of these functions for you so you don't even need to worry about that particular detail so how do we use it well now I'm going to declare a promise chain so now things are vertically oriented rather than nested so when I make my first function the most important thing is that I create a new function and return it from the success of the previous one which chains the promises together and creates an ordered sequence of events okay so promises can definitely solve some problems it makes code a little bit better but most importantly promises are solving inversion of control issues and I've written a bunch about that if you're interested but the real awesomeness comes from generators this one of the things I'm most excited about I don't have time to teach how generators work but essentially it's a locally possible stack inside of a function so the function itself can pause while not blocking the rest of the function which gives us synchronous looking asynchronous code it's the best of all possible words so now we can just say equals and it's just going to magically wait with that yield keyword it's going to wait until this asynchronous promise thing comes back so now we write synchronous code and by the way there's also synchronous error handling you can just try catches around these statements and catch errors and things like that generators are amazing but there's one problem with the generator you notice I've declared this new thing but I'm not showing you how to run it and the problem is there's some plumbing there's some utility that needs to be added to make this work by itself to be able to yield out a promise and have that promise resume the generator and so forth there's some utility plumbing and it's about 20 or 30 lines of code most people in this room could probably work their way through figuring it out okay I'll do a promise not then and I called up next you could probably work that out but you don't want to and you don't have to because all the libraries out there that are worth anything already have a utility built in for it mine happens to be called runner so that's just built into the library it's called spawn in the queue library and something else and bluebird or whatever but all these libraries out there have a thing where you simply pass your generator in and all that plumbing is taken care of for you which is awesome but it's not as awesome as it perhaps could get because there's a proposal it's not a guarantee but it's a likelihood that in the next version of JavaScript ES7 aka ES 2016 we're going to get an even nicer form of this which is the async function this is a new kind of function similar to the new kind of generator it uses the async keyword instead of the star and it uses the await keyword instead of the yield keyword otherwise it's still the same synchronous looking stack but the nice part about this is you notice I'm literally just running the function with no library whatsoever because the language knows how to do all that plumbing utility for us this is a big win in a lot of cases now async functions a lot of people that are talking about this are saying why do we even need to learn generators because async is so amazing and it's true that async is amazing except that there's some limitations so just like I talked about with arrows and with everything else this is not your blind do everything in it there are some caveats there and you should pay a closer attention I think you would be well served first learning how the generator and promise pattern works and using a good library to help you with that and then once ES7 async await comes around it'll be a simple easy change for you so this is pretty cool stuff we got one more set of things to look at oh by the way this in the previous one we were dealing with a very sequential set of statements do this then do this then do that this also works when you need to deal with things in parallel aka things that are concurrent so here what if I wanted to make three Ajax requests at the same time and wait for all of them to come back but make sure that I respond to them as soon as possible but I respond to them in order that's kind of a complex pattern that we have but it's often very common and you use your interface to do that here we do it with promises we're letting the promise maintain that state and we declare a promise change so this is a lot better than the nested callback form would be without needing to deal with state so this is kind of good but still kind of a meh but the awesome part is that now inside of a generator we can simply ask for those promises and then call yields on them that's about as clean as I've ever seen that sort of logic be expressed and I'm using that kind of code all over my code bases now it's super improves so that I can now reason in a very linear sequential way about how my code works I don't have to my brain doesn't have to jump all over non-local ways all right I hope that's not a man hope that's a okay all right so one more thing iterators iterators are if you know about that pattern it's very similar in javascript and iterators a patterned way of stepping through a set of data so the data structures that are existing in javascript for the most part have the iterators now built into them for example arrays and strings they have iterators built in so if I wanted to pull out the values from this array the old-school way the boo way of doing it was I had to actually iterate not over the values but over the indexes and by the way if there were prototype inherited properties then that stuff sucks but I could iterate over those properties and then pull the values out we now have a new loop in javascript that takes advantage of the iterator syntax and it's the four of loop and it loops over the values that are produced from an iterator arrays or iterators generators or iterators maps and sets they all have iterators attached to them so we can have a patterned way using syntactic looping structure to go through a sequence of events now what's that yes but it uses a destructuring syntax and you have to use it your own iterator syntax but we'll get into that here but yes you can do the PHP key value thing you can pull that out okay so iterators are awesome on arrays right what about our objects can we iterate over objects and this kind of sucks because that doesn't work you because objects don't ship the plain old simple object they don't ship with an iterator one there's many reasons why but one of the reasons they don't ship with an iterator is that it's not actually fully defined what what that would mean what order should they go in should I remove properties or not remove properties what about inherited properties there's a lot of complexity there so rather than forcing that upon us developers they did not ship iterators on regular objects which seems like a limitation seems like it sucks but it turns out we can define our own iterators using what we're what are called symbols here I know the syntax may look a little strange but I'm declaring a generator that can yield out these values and I'm in a pattern way saying what I want to yield out whenever you do a four of loop over my object so I think I can declare my own iterators for my own data structures and by the way that yield star that's yield delegation we're actually yield delegating to the iterator that this dot b property is which is an array and it's just from the outside it doesn't matter it just continues to work there's a ton of really awesome stuff and this is the fastest run through that's probably ever been done over this amount of ES6 features but I hope that maybe this stuff is getting excited that hey it's time to go improve some of my ES6 code there's not a lot of new functionality per se but there's a whole bunch of improved way of doing the stuff that we did before so hopefully you're excited and then we start to ask how am I going to run this in browsers because oh my company forces me to run IE 8 right and this stuff is not going to run in IE 8 right so but ES6 browsers are just totally ubiquitous there's no problems right and unfortunately not exactly right so boo right because I just got you excited about all these great features but how are we going to use it well it turns out the way we're going to use it is to transpile this is a huge win for the JavaScript community to not have to be held back ten years to wait around for stuff because we've built tools that will take all that great new ES6 syntax that you wrote and convert it into the old crappy code that you don't want to write anymore the old crappy code that still runs in all those old crappy browsers so you insert that into your tool chain just like you have a minifier and a linter and a compressor and all those other things you just insert another step in there that does the conversion which we we have to invent our own names for everything in JavaScript we call it transpilation so Babel is by far the most popular of these transpilers that are out there this is a live web page repel for it and I'm not going to zoom in here but on the left is that previous example where I was declaring an iterator an object and on the right is the amount of code that it would take to do the same equivalent yourself in ES5 how many of you would like to write the code on the right okay that's cool maybe one in one in a crowd how many of you are excited about being able to write the code on the left and that still run right you see the visualization here that there's an awful lot of code that we're removing automatically because we're allowing the language to do more of the heavy lifting for us so that's a great thing for us also for that's for new syntax for all the new apis that have been added we have polyfills you could write your own polyfills but turns out they've already been written for you and they're spec compliant and they're tested cross browser this one's called ES6 shim you should just go get it and you could use a couple of them if you only needed a few of them or just use the whole library it patches all that environment and a polyfill makes it so that the environment looks like it's up to date even if it's an old browser okay and by the way there's polyfills for ES5 as well so even if you're running an old crappy high six you can polyfill that up to ES5 and then polyfill that up to ES6 that's nuts but you can do that not wait that way you write one code base and you don't have to worry about the environment that it's running polyfills transpilers they seem to solve this issue of us being stuck ten years behind and it's exciting but the real question I want to ask you is what ES6 features do you need maybe I got you excited about two or three of them a few of them jumped out at you like I'm gonna use that arrow function I'm gonna go use that let block scoping declarator or something like that a few of these things jumped out at you a statistic that I love to quote 96% of all JavaScript programs need less than 37% of ES6 features and by the way those figures are totally made up with the point that I'm making is that you don't actually need all of ES6 there's a ton of really great stuff there but remember that list I don't know that I'm ever gonna see a program that is using every one of those features you're still gonna be writing this mixed mode if you will a lot of regular normal plain JavaScript mixed in with the ES6 stuff so then we turned our attention to browser support this is site called ES feature tests I'm sorry not ES feature but it's a ES6 feature testing site so it's built by a guy on Twitter named Kengax but this is current testing all the current versions of the browser so let me just zoom in here real quick this I did actually ran this on the Microsoft Edge browser and this was run a couple of months ago but if you really really squinted you'd find out the Microsoft Edge is actually leading the way they have more ES6 support than any other browser and that's still true today it's not your old IE that you're used to they're leading the way in the standard supports the point is if you went across the screen you looked at all these different browsers there's no browser practically that's down at zero percent they all have some of it and in fact most of them are above 50 or 60 percent there's a pretty good chance that your code the one the features that you're going to write don't need any transpilation at all at least for some of the browsers so going back to that old transpilation stuff are we going to ship all that old crappy stuff to the brand new browsers and not be able to take advantage of all the new ES6 features that they're landing let me ask this what if we just told the browsers you're off the hook you don't need to implement any new features because we're just going to simply specify new stuff and then create transpilers and the browsers never need to update and we'll just always for the from now to the end of time we'll just always ship the old crappy transpiled code does that make any sense to anybody that seems crazy to me but that's basically the current strategy that a lot of people seem to have I don't worry about it just transpile everything it's one of those magic black boxes but when you look under the covers you're like wait a minute and generators are one of the worst offenders because it not only needs this much syntax but there's a whole library that has to come along to support that generator running so I use generators a lot I think this kind of stuff sucks and I would rather be able to tailor what I'm transpiling to the browser that it's running it I'd like to have versions of my code that could run as much of the native features as the browser has so these transpilers and polyfills there's a bunch of stuff that can't even be done transpiling for example many of the well-known symbols can't be transpiled we can't subclass natives the underscore underscore proto property tail call optimization and many others these are things that literally flat out can't be transpiled but I'd like to use those features in browsers that support them so I kind of let some air out of the balloon right I got you all excited about this transpiling and polyfilling but when we peel back the covers it's maybe not so wonderful but feature testing is awesome right because what we could do is run feature tests inside of the browser to know what it actually supports and then load the appropriate version of the code either the transpiled code if the feature fails or the non-transpiled native ES6 code if that's going to run in our browser so it's easy to test for API's just simply say is it existent or not that lets you know if you need to load a polyfill library for example we're not syntax like the arrow function might think I'll just stick it inside of a try catch unfortunately that doesn't work because the try catch is not deferring the compilation of this code so the JavaScript engine is going to see that arrow not know what it is and just simply choke before it ever has a chance to run so actually what we need to do is defer the compilation using a function constructor or the eval function or some crazy crap like that and then you start thinking about all the ES6 syntax that's a whole bunch of tests how many in here you want to write all those tests for yourself I didn't think so I was crazy enough to write those tests and build a library for it so this is a website that I launched that serves up the library or you could use the library yourself it's the library is called ES-feature-test but feature test on IO you load the library into your page it does the feature test for you it gives you those results back and it lets you know what features are present or not so you simply test for the features that you care about and if they're present in the browser load the native ES6 and if they're not load the transpiled code and all these features are available to you so what I'm going to switch over to in our last couple minutes here I want to show you this is that site running so this is mine that it's running in here and you think well it's running some feature test what's the big deal well actually for performance reasons there's a whole bunch of stuff you might want to do for example you might want to run these off thread in a background thread like a web worker so it doesn't slow down the page my library is already taking care of that for you you could write that your logic yourself or you can use the library you might also want to cash these results like in local storage because the browser is not going to update every single day with a new feature so maybe not run them every single day maybe run them once every two weeks for example so it's already taken care of caching oh by the way what if you could cash it in a way where all sites could take advantage of those results because you could cash it in a cross-domain fashion so that every single site on somebody's browser that's using this library gets to benefit and the test only get run once so they actually don't have to run very often at all all that stuff is stuff that's taken care of with this library so you could do that yourself or you could use it alright so that's part of the story but then the question becomes I've got all this great ES6 code there how am I going to know which of the features I'm using I have to manually keep track and remember whether somebody ever used the let keyword or whether somebody ever used destructuring syntax or whatever so the other side of the puzzle is how do we figure out which features we need and that library that I wrote comes with a command line tool that you can use and it parses your code and it tells you which ES6 features you're using so you know which tests to run so you can make this a fully automated process where you run the tests I mean you run the scanning to figure out what tests you ship that code to the browser you do the feature test in the browser and then you figure out which code to load it's fully it's fully automatable so just real quickly I have that file and if I do if I try to run this utility it's called testify and I give it the file food.js that we just saw it comes back with JavaScript code which you can ship to the browser and it automatically uses the results from the feature testing library and returns you a true or false so you don't have to do anything except call the function and ask did I get a true or false and that decides what code you want to lose and by the way this tool has a whole bunch of configurations that you can use on it to change the output to JSON if you want to use the output in JSON instead of code you can actually use it to produce configurations for Babel or Tracer so that you can customize what Babel and Tracer are actually transforming and not transforming so you could turn off generator transpilation for example so this tool ships with it with the library for free all right so wrapping up here I don't want you to shy away from ES6 there's a bunch of amazing stuff and you should be using this code right now literally today go home and write some ES6 code go home and improve your code to ES6 I'm not trying to be all gloom and doom about it I'm simply saying we need to be smarter and more intelligent about how we set up a process because a lot of times we think I'll just be able to update some configurations at some later time but a lot of the reality is that we write code and then we leave that team and nobody maintains it before and then that code just sits forever so what I'm trying to give you is a strategy that will constantly keep the code most optimally running in the browser and it will put you on the front edge of this gap rather than on the leading edge so there's always going to be this ongoing gap that's the new future and JavaScript is going to be improving itself constantly by feature by feature and year by year basis there's constantly going to be the gap and the solution to that gap is not only to use those tools like transpiling and polyfilling but to make sure that we have a strategy that's serving the best code to the browser here's my little arrow function joke again transpiling and polyfilling is really about developing for the current and the future setting yourself up so that this code continues to run most optimally even if every single developer walks away and forgets it I really think that we need smarter strategies and serve the right code for the right browser and I just this morning published a blog post with more of the details about that strategy and how you might use these tools together so if you're interested in reading more about that concept I'm excited about ES6 I hope this gave you some more tools to dig into remember that I've got a book out there there are other ES6 books that are great to but I will definitely tweet out these slides I encourage you to go back and check those links and the link to the ES6 book is down there at the bottom of that slide as well so thanks very much and I think this is rare for me but I might actually have a couple of minutes to take a couple of quick questions if there are a few I think we need microphones make sure we get a microphone to thank you very much by the way sir hey we got matching shirts so that's yeah I want to talk to you about that yeah there's I was wondering if there's a book or anything you've written about async programming just having our time keeping up to speed with it sure sure it's great that you asked because I did write a book about it okay I thought maybe there was the fourth in series called async and performance and it lays out all that stuff with promises and generators and async functions and how that stuff works great and then second question real quick I've got a cousin in Atlanta that wants to do a coat school do you you're not in it we don't have an Atlanta presence yet but that would be awesome to open up Atlanta would you put them in touch so we can at least figure out maybe yeah maybe be willing to go yeah definitely put them in touch that'd be awesome great yeah I have I have a philosophical objection to to using feature testing and feature detection to to decide whether to use code or not okay and the problem is that browser seem to have bugs sometimes and so you say aha this feature is there and so I don't need to do this and then there's a bug in your code because there's an underlying bug in the in the browser that particular feature which hasn't been quite implemented properly so you have any comments on that yeah absolutely it's a fantastic question just to reiterate the question basically is what happens if I feature test for a feature but it's not been properly implemented yet or maybe it's still experimental or something like that fantastic question the answer is that your feature tests are much smarter than what you're probably conceiving your feature test is not just simply checking does the syntax there but it can also test the behavior of these things so if you dig into the feature test if there's some particular bug that's well known and it's in a browser that's going to be around a while you simply construct a feature test that checks not just the existence of the feature but it's proper behavior and it only passes if both those tests pass so we're already looking we already have that built in and there's more of that so that ES6 chart that I talked about before the Kangaq chart on support if you go through and look at all his tests a lot of them are not actually about the feature being there it's like here's the test for the feature being there and then 15 tests to make sure that it behaves correctly in all of its nuances okay thanks for the great talk and the JS books series yeah my question is on transpiling the problem with that is you know for debugging the programs you cannot does it point back to your source code or the or the transpiled code because fantastic question what if the code that's running in the browser doesn't even remotely look like the code that I authored how am I going to debug it what are my stack traces going to look like fortunately this problem was solved actually four or five years ago with the thing called source maps and they saw that actually for minification of code but now it makes sense also for transformation of code what a source map is it's produced by the tool that's converting your code and it's a mapping a line by line and character by character mapping from the new code the stuff that you didn't write back to the old code the stuff that you did originally right so the ES6 code and the browser sees the source map annotation it loads it up and when it shows you the code in the browser when it shows you the stack trace it's showing you the natively authored ES6 code not the code where the error actually ran so source maps have already sort of you know maybe 95% fix that problem there's a few nuances there but it's really powerful these tools are all source map aware and then I'll definitely I think I think I'm standing between you and lunch if I remember correctly and I don't want to do that so yeah I know so one more quick question and if you have others definitely come up and reach me the rest of the day yes you seem to mention the example showing parallel functions there parallel functions parallel computing like you have to use the promise yeah so so the question is is asynchronous the same thing is parallel and actually no actually my question is that the specification ESC is their parallel JavaScript yeah they have abandoned parallel JavaScript but that's why WebAssembly wasm is out because there are going to be other languages that are much better at parallelism and those can transpile the stuff that'll run in the browser so JavaScript itself as far as I know it's not going to have parallelism it's really good at concurrency which is good enough for most cases and then when you need parallelism there's other options okay all right fantastic thanks so much for being here