 OK, next up, we have Patrick Dubry, Dubry, sorry. Patrick's a bit of a web guy. He published research into the way people used tabs in 2010. Since then, he's worked on the Android team. And now he's working on the Google Chrome team. He's also a big ice hockey fan, he tells me. Let's give him a big round of applause, Patrick Dubry. I always wanted to speak at a conference where I could walk on stage with theme music like that. Although I always imagined it was going to be a replacement song instead of this, but I'm not too picky. So I think Jeremy's talk is a really good lead-in to what I want to talk about today. I want to talk about the future of the JavaScript language. And right now, the near future of the JavaScript language is something that's called ES6. So ES6 is the sixth version, the sixth revision, of the ECMAScript spec. And most of you probably know ECMAScript is basically the standardized name of the language that we all know and love as JavaScript. But before I talk about the future of JavaScript, let's talk a little bit about the past. So JavaScript appeared in 1995 in the Escape Navigator 2.0. It was famously created in, I think, seven days or 10 days. I can't really remember, but a very, very short period of time. Now, you may not know that JavaScript is actually a trademark term, which is why when Netscape and Microsoft and a few other companies wanted to standardize the language, they decided not to call it JavaScript in the standard. And they took it to the ECMA standards body in 1997, and that's how we ended up with the name ECMAScript. But Brendan and I had said that this is, sounds to him more like a skin disease than a programming language. In 1998, they followed it up with a second revision in the spec, ES2. And then in 1999 came ES3. Now, how many people here were writing JavaScript in 1999, 15 years ago? OK, a few hands, not too many of you. I think this was the year when I really started seriously programming. Like, I got a job as a programmer, and I was writing JavaScript. I have to say, I don't think I remember the world before ES3, because before ES3, JavaScript had no function expressions. There was no try-catch and a few other things. So I don't really remember that world. But ES3 is basically what we know of as JavaScript today. So after 1999, there was kind of this long winter where there was not a lot of talk about future changes to the JavaScript language. And anyone who was around then also remembers that there wasn't a lot of innovation in the browser space either. And that's because we had a single dominant browser between about 1999 to maybe 2004 or 2005 when Firefox started getting popular. And around that time, people started talking about a new version of the spec and standardizing on some of the features that it popped up actually from ActionScript of all places. And this was a really, really big spec. It included things like classes and modules, but it also had optional static typing. And this was such a huge spec that, in fact, the committee could not come to agreement on how to ship these features. And in 2008, they basically decided that there was going to be no such thing as ES4. They completely canceled work on ES4. A finalized version of that spec never happened. And instead, they decided to focus on a small set of features that would be launched in ES5, which came in 2009. And they deferred work on the bigger things, like classes and modules, for a future version of the language, which they called Harmony. Now, five years have since passed since ES5. And we are now getting very close to having this Harmony language. And that's what ES6 is. So if you've ever been confused why sometimes you hear these features referred to as Harmony features, sometimes ES6, it all comes from that decision in 2008 to end work on ES4. So work on ES6 has been ongoing for the past couple of years, but the spec is actually starting to get pretty stable now. And the last I heard, I think they're targeting end of 2014 to have a final spec, but it's possible that could get pushed back a little bit. But a lot of the features are getting really, really stable. They don't anticipate too many changes at this point. So there are a lot of cool features that are coming in ES6. And today in my talk, I want to tell you guys about some of these features. Some of the features that I really like, there's much more than listed here, but classes and modules are obviously something that people have been looking for in JavaScript for a long time. We have arrow functions, destructuring assignment, the spread operator, default parameters. One of my favorite things is generators and iterators. This is a really, really cool feature that I want to go into a bit of detail on near the end. In Jeremy's talk, he talked actually about a lot of these features. You've seen some of these things before in CoffeeScript, like arrow functions. Actually, the arrow functions in ES6 were really influenced by CoffeeScript. And that just shows the power of experimenting with language features and how that can have an influence on the standards process. Other things coming in ES6 are things like promises, maps, weak maps and sets, a bunch of built-ins to string, number, objects, math functions, array, all kinds of good stuff. Now, currently, support for these features kind of varies between browsers. So many of the features are currently supported in Firefox by default. But Chrome has taken sort of a different approach. Chrome and the V8 team, all the ES6 features in Chrome are actually behind a runtime flag. So you can turn these on by going to Chrome Flags and turning on Enable Experimental JavaScript. In Node, of course, it's based on the same V8 virtual machine. So the same features or basically the same set of features is also available behind a Harmony flag. But if I turn on this flag in Chrome and take a look at the compatibility table for ES6, it turns out that Chrome, even when I have this flag on, there's a lot of stuff that's read there. So this shows that the Chrome team is actually taking a fairly conservative approach to developing these features. We're participating in the standards process, for sure. But the thing is that we've seen what can happen when new features that aren't finalized get released into the wild. And I'm sure you've all had to deal with the headaches that come with CSS prefixes. CSS, where you have six different prefixes, because the thing is, as soon as people have this stuff on the open web, they'll start to use it. And I know Flexbox, for me personally, has caused tons and tons of pain. The Safari on iOS supports a different version of the spec. And they had to keep changing the names of the properties to distinguish between which version of the spec they were on. And it was really just difficult to deal with. And this is why on Chrome, we've been much more conservative and waiting for the features to be finalized before they're adopted. But even once Chrome and Firefox and other modern browsers start supporting these features, of course, we all know that it's going to be a long time before you rely on the users of your website having these features. So what I want to talk about is how you can actually get access to these features today. Now, the features that I listed earlier can roughly be broken up into two different categories of features. The first set, so classes and modules, arrow functions, destructuring assignments, stuff like that, these all represent new syntax, new language syntax. So this is something that these are all things that would not be recognized as valid JavaScript today. Second set of features like promises, maps, week maps, et cetera, these are basically library features. And probably a lot of people have experience dealing with library features that are missing. We tend to use polyfills, and as Jeremy pointed out, many polyfills can cause problems. But for the most part, I think people have a good way of dealing with this. As long as you're careful, you can get the functionality that you need, or you can use a library that provides the functionality you need. So I want to focus on this new syntax part. How can you get access to the new syntax today without locking out anyone who's not using the latest version of Firefox or hasn't turned on this flag in Chrome? And one way to do that is to use a compiler like Tracer. So Tracer is a compiler that compiles JavaScript.next, so ES6 features, but also it also supports some proposed ES7 features. It compiles these down to the JavaScript of today. So in principle, it's actually quite similar to CoffeeScript in a way, at least how you integrate it into your development process. Tracer means that you can write ES6 code, and if you have a build step, you can compile this code down to ES5 that you can deploy. Or in most cases, actually Tracer generates ES3 code. I'm not sure if it's quite as good as CoffeeScript at explicitly targeting ES3 features. So one question you might ask is, why would you want to do this? So I think the first answer is obvious, because a lot of these features are really, really cool. And people loved CoffeeScript because it provided all these nice syntax, new syntaxes, new sugars for doing things, sometimes in a safer way than they were doing them before. That's obviously one reason. But a second reason to use ES6 features today is that you can actually help shape the future of the language. ES6 is getting close to stable, so there aren't going to be many changes, but ES7 is still kind of up for debate. And so with Tracer, you can use not only ES6 features, but also ES7. And you can actually try these out in your code and go on ES discuss and actually tell the committee what works for you and what doesn't. And I think this is tremendously powerful. And I wish more people would be involved in the standards process. CoffeeScript, we've seen, has had a really nice influence on things. So to use Tracer, it's pretty straightforward. It's very similar to using CoffeeScript, or if you're using something like Uglify.js in your build process. From Node, you can just, there's a programmatic API you can use if you require Tracer, and you can call the compile function. There's also a command line script you can use, which is what I use. So it's very, very simple to use. If you're using build tools like Grunt or Gulp, there's also plugins for that. And if you're using Browserify, and I'm a really big Browserify fan, there's also ES6ify, which is a Browserify transform that wraps Tracer. But you can also even, I mean, I'm using Browserify, and I still just use the Tracer command line in my build process. It's really simple to use. So let's look at some of the features that Tracer can give you access to. And I wanna show you what it looks like actually when these features get compiled down to ES5 syntax. So one of the features that I really like is arrow functions. I think these were quite inspired by CoffeeScript syntax for this. These basically give you a shorter syntax for function expressions. So you can see, I just have a bare arguments list here. So no function keyword, and no curly braces, and I also have an implicit return. So there's no return keyword, but the result here will be returned. It's this, these semantics are exactly the same as CoffeeScript. And this compiles down into ES5 or ES3 syntax in a pretty straightforward way. Basically just compiles into a straight function expression. Let's look at something a little bit different. One of the other nice features of arrow functions is that they have a lexical this binding. So Jeremy talked about this a little bit earlier. I'm sure everyone has made this mistake before where you have some function that takes a callback and inside that callback, you refer to this. But you didn't mean the dynamic this inside the callback. What you really meant was this binding outside of the callback. And of course, if you try to run this code, you get some kind of error that looks like this. And most of us have seen this thing so many times that we know exactly what we need to fix. So arrow functions actually fix this problem. Inside arrow functions, if you refer to this, it's not dynamically bound. It's actually bound in the scope outside, basically the scope in which the function is declared. And I'll show you the way this is, how this compiles in tracer. It basically mimics what most people are already gonna do by hand, right? Typically you do something like var self equals this and then inside the function you refer to self. But with tracer and arrow functions, this is all done for you. So tracer will generate a variable here and basically it prefixes all the variables that it creates with the dollar sign and it will pick a variable name here that is not in use in your code, right? So if you happen to have something called dollar sign underscore underscore zero, it will pick something different because tracer is analyzing all of your code. And then basically it uses that same binding inside the function. So this frees up a big class of errors that I know personally wasted a lot of time for me. Another nice new piece of syntax in ES6 is destructuring. Jeremy showed this. This is another thing that CoffeeScript has. It's a small thing but it's very, very handy, I find. You can also destructure not only from arrays but also from objects. So if you'd need to just pick out the fields, a couple of fields out of an object that has many more fields. Let's take a look at how tracer compiles this down. It's actually quite similar to how the lexical this binding is implemented. So again we have this temporary variable that gets created by tracer and it assigns the object or the array to that variable and then takes out the fields that it needs. Another nice thing that we have in ES6 is the spread operator. So it basically allows you to unpack an array into another array in place. So in this case I have two arrays and I smash them together using the spread operator. You can also do this in function calls which is super handy and means that you don't have to mess around with apply which, this is all stuff you could do before but it's kind of messier and it obscures the true meaning of your code. And so this allows you to, as the guys on the tracer team say, this allows you to say what you mean. So let's look at how tracer compiles the spread operator. This one's a little bit different, right? We've actually got a reference to a runtime function here. So this is one thing that's really important to know about tracer is that some of the syntaxes actually require a little bit of runtime support code. And this is not a massive library that you need to include. I think it's about 50K unminified. It's very simple to include. From node you can just require tracer bin, tracer runtime or of course you can also just add a script tag if you're running in the browser. Another nice feature similar to spread is called rest assignment. And this is sort of like unspread I guess. So we'll take, if you have a destructuring assignment and you have only two elements in your assignment here but three elements in the array, then the first variable in your destructuring assignment will get the first element of the array and the rest will go into the second element of the destructuring assignment. And you can use this in function declarations as well which again is really handy. It probably means that you never have to touch the arguments object again, which is very nice. More good stuff that's coming in ES6 is template strings. This is, you can do actually quite a bit more with tagged template strings which are really cool. The object initializer shorthand. Once again these are things that you may have used in coffee scripts. And I'm a big fan of coffee scripts which is actually why I like to use these features in ES6. I find that it gets me about 80 or 90% of the way to coffee scripts. Of course we finally have classes. This was one of the features that was talked about in ES4 and it's been a really long time coming to JavaScript. And Jeremy in the last talk really pointed out the benefits of this. Even though it's really something that you could do before, it's a much nicer syntax. And again it lets you say what you mean, right? JavaScript is incredibly flexible and you can do lots of stuff with the prototype chain and not all of it is the same as classes. And so the class syntax actually compiles down to basically the idiomatic way of using prototypes as classes in JavaScript but it lets you be more explicit about what your intentions are. So I thought I should also present something that's actually not in coffee script. Modules is another thing that was a long time coming to JavaScript and in fact it's still not quite finalized. There's still been a lot of discussion about this and it's something that you can use today in Tracer but you should be aware that there's a good chance this syntax will still change before the spec is finalized. But still it's good to play with these and if you have feedback, if you have use cases that don't work, you should absolutely go on ES discuss and tell people. And the cool thing with Tracer is it will actually compile these modules down to common JS modules if you want or AMD modules or it can put everything in line into a single script file. So this is really handy if you want to use ES6 modules in your code. Personally I'm a big fan of using browserify and require so I don't have a whole lot of experience but I have played with these a little bit. So that's a bunch of the cool features that are coming in ES6 but I wanted to save one more thing for the end and the reason I wanted to save it for the end is because this is actually my favorite feature that's in ES6 and I think it's one of the most powerful features that's been missing from JavaScript and I'm really excited to see what people do with this once they have access to that. And this feature is generators. So generators are introduced a few different types or a few new types of syntax. The first thing is this function star syntax here. So this marks this function as being a generator function and a generator function is something, even though it looks just like a regular function it's actually something different. The other piece of syntax that it introduces is the yield keyword. And so if you've ever used generators in Python then you're already familiar with the way that generators work in ES6 but if you've not seen them before it's I think it's a really, really powerful concept. So a generator basically works like this. When you call a generator function it doesn't return the value that you would expect. Actually what it returns is a generator object. And a generator object has a method called next. And when you call next it will basically start running the function and produce a value from the first yield statement that it encounters. And it will return this object that has that value from the yield as well as a boolean which indicates whether the generator is done or not. And so basically the next time basically the function will get paused and the next time you call next it will re-enter the function at the point of the yield. This is really, really cool and it's a really powerful way to represent things like infinite streams. Typically you probably won't be directly calling next like this. Instead you'll be using the new iteration syntax that's coming which looks like this. And we have rather than var x in whatever it's var x of and this basically under the covers will create the generator and call next until the generator indicates that it's done. So generators are very powerful and as such they're actually probably the most complicated transformation that tracer has to do. This is just about half of the code that tracer generates for the generator that a generator function that I had on the last page which is probably the simplest possible generator you could write. But it gives you a sense of how much power is hidden behind generators basically because it pauses the execution of a function. What tracer unrolls this to is basically a big state machine. And whenever you call next you're gonna jump back into this state machine and resume execution at the point at which you left. So it's really, it's a bit of a complicated transformation and that really highlights the fact that this is something that would be extremely difficult to do before. One last thing that's really cool about generators is not only does this yield keyword return a value basically out of the generator it also returns, this is also an expression that returns a value inside the generator. And I'll show you an example of this. This is another thing that makes generators even more powerful. So if yield was not an expression and Python was like this originally when they introduced generators then generators are really kind of only good for a few things like infinite streams and stuff but by the addition of this you can do some really, really powerful things. So for one we can actually, when we call next we can pass in a value and have the generator the generator function itself react to that value. So in this case rather than having a completely infinite stream of numbers I can actually stop the generator here. So the value gets injected when I call next. So I can pass an argument to next and this argument will actually get assigned here to the stopped variable. So you basically have something that is kind of for those of you who are familiar with them, coroutines. Now I have to put an asterisk beside this because they're not quite coroutines. They're sort of a restricted form but arguably it's actually better because it really makes explicit where the yield points are in the code and this is something that's important in JavaScript. We've always been able to operate under the assumption that our code doesn't get paused at an arbitrary time and with generators that's still the case. You can see by inspecting the code where the yield points are. So in my opinion this is in some ways better than actual coroutines. So that's just a brief introduction. You can really do a lot of powerful stuff with this. If you're interested in this I encourage you to check out a couple things. First check out task.js and there are many more projects that have proposed using generators as the basis for interesting concurrency primitives in JavaScript and this is why I'm so excited about it because concurrency in JavaScript has been one of the curses of JavaScript kind of as Jeremy put it, right? We've never been quite sure what the right way to do things is and I'm convinced in like five years that we will have a much better solution that's based on generators. Generators really give a nice primitive for building all kinds of concurrency constructs. I also wanna point you to Facebook has a project called Regenerator which is a compiler that's similar in spirit to Tracerer except it only does generators. So since, you know, this is my single favorite feature of ES6, if you wanna just play with generators you can also, and you don't feel for whatever reason you don't wanna use Tracerer you can also try Regenerator. So that about covers the things that I wanted to talk about. If you're looking for additional information you can check out the best place to look for information on Tracerer is the GitHub page. For ES6 in general, Adios Manny has a really, really good list of all kinds of tools for transpiling ES6 for polyfills for ES6 features, how to integrate it into your build process, things like that. So you can check that out. My slides are online at this rather obscure URL but I'll send them out on Twitter later. And if you wanna talk more about any of these things, you know, of course I'm gonna take questions afterwards but also please feel free to grab me later today, grab me at the break or at the bar tonight or anything like that, I'd be happy to probably talk your ear off about generators. So thanks. Oh, someone who used to work on the V8 team is about to ask me. I only work near the V8 team. Okay, but this is not about V8 or G. Since your research generators a lot. I actually was going to implement generators in my programming language with Macros and so on but I've been very slow at doing that because when I analyzed the use cases for when using them for coroutines I wanted to be able to save the state. So if you have a generator running in a server and it's something like an asynchronous flow then if something goes wrong in the middle and you want to restart the thing and you want eventually to restart that in a different server, in my opinion you are sort of screwed unless you can sort of serialize the generator state and revive it somewhere else. And I wonder, I don't think this kind of semantic has ever included or contemplated in the spec but are you aware of somebody just thinking of something like this? So if I understand the question correctly you want to be able to essentially clone a generator. Is that like, you want it to not be a one-shot generator? I want a coroutine that can be migrated. They can be what? Migrated. So yes, clone it and transfer it. Okay, so we're talking about like serialization and migration. That's a really good question. I haven't, I'm not familiar of any languages that have implemented this. The only thing I can say is there was a really great paper that was published, I don't know, a few years ago and I can try and dig it up for you later if you want but was basically analyzing how generators work in Python and JavaScript and how coroutines work in various languages and how continuations work in various languages and just kind of like was it was a survey of all the different implementations because these constructs are all very similar, right? In a lot of ways. So maybe that paper talks about some language who has done effectively the serialization. But in some way it feels like with the output that Tracer is generating that you could actually serialize. Well, what I saw, you've got a context variable. If you serialize that, it's probably going to work. Yeah, but I think it's doable. But if nobody does it, I'll do it myself. I mean. It seems like it should be doable. We got another question? Anywhere. I've got one then. How long until we see all of these new features? I was just looking at the compatibility tables and it seems like Tracer's got about 50% of stuff in there, maybe Chrome was sort of 15%. When would you expect this just natively to either be in browsers or be in Tracer? Good question. So as for Tracer's support, I think the majority of syntax features are actually are there. So if you look at the compatibility table, you'll see a lot of red. But that's partly because Tracer has not been focusing on the library features because these are things that can be addressed with polyfills. I know there are some features that are still not complete in the spec. So I believe the let syntax is still not 100% finalized. And modules I mentioned. So some of these things are not 100% supported in Tracer yet just because they're not finalized in the spec. I personally don't have a whole lot of insight into, I read the TC39 notes and follow AS discuss, but I don't really know. I can't really say like when I really think things will get finalized. Cool. Thank you. Round of applause to Patrick.