It's awesome to have him here to tell us a little bit about what's going on with JavaScript, so Domenic Denicola.

[APPLAUSE] All right, JavaScript.

So where did this all start, this whole JavaScript thing? Well it started in 1995, back when we were doing form validation, and image rollovers, and hiding the URL where people went in our Status Bar back when browsers allowed that.

So that was the point of JavaScript when I first picked it up.

And that was really fun.

But I think it's grown a little bit since then.

But it's been a slow process.

So, first we had to standardize the language.

We had to take this thing that Brent and I had made in 15 days, or 10 days, or whatever it is, and put it into a spec, and put it through ECMA.

And we had to come out with some competing implementations.

So my favorite is Internet Explorer 4, because that's when this whole DHTML craze started.

I don't know if you remember DHTML but it made some really fun websites.

That was the first time we could actually make things move around the screen, with document dot layers and document dot all.

Document dot all still haunts us today.

It's a falsy property that has properties.

It's like horrible.

But that was the HTML, and yeah.

So skipping forward a few years, we standardized the next version of JavaScript language.

And it's fun to point out the things that were added in ES3.

Because there are a lot of things that we take for granted today.

We don't really realize that the language has evolved so much over time.

Things like function expressions which you use all the time today, that's all that CoffeeScript supports.

It doesn't even do function declarations.

Those came in a new revision of the language.

Try Catch Finally and Regular Expressions, if you can imagine JavaScript without those, that was the case for four years on the web.

And there was this kind of lull for many years, right.

And the W3C was pushing all these XML solutions for our problems.

And we were going to make all of our websites out of XHTML 1.1 and 2.0, and

SVG, and XEvents, and all that.

So in 200r, a new group broke off in the W3C, called the whatwug, as I say, or the WHATWG, as they call themselves.

They focus on the web applications, and the idea that now it's time to actually start building rich interactive applications on the web.

And that's where JavaScript started to kind of see it's new Renaissance.

Now we're going to say, the web is a platform for applications.

And things like Gmail and Outlook started popping up around this time.

And speaking of Outlook, Microsoft Outlook Online was where we first saw XML HP requests and AJAX, which stands for Asynchronous JavaScript Adjacent.

So that was really the first time that we could do the whole server interaction.

And first it appeared as ActiveX Control, but then it was exposed to JavaScript via Mozilla, put it as a property of the global where it has appeared ever since.

And as you can see, things were starting to pick up speed.

Now I don't know the first time you guys remember using jQuery, but for me it was pretty exciting to finally have a unified API that solved all these cross browser issues and all these-- I could add events with a single signature in all these browsers.

So jQuery started coming out and made JavaScript popular to the masses.

And for a lot of people, perhaps many here, that was our first exposure to JavaScript at all.

You still see the job ads, at least in the US, for, we need a jQuery developer.

They don't mention JavaScript, so it's kind of sad.

But anyway, things started really picking up over the last few years.

In 2008, V8 was released.

That was only a short time ago but it's hard to underestimate how much it has impacted the JavaScript landscape ever since.

The speed that they brought to the table was so far ahead of any engine at the time.

If you see the charts for the speed rates that took off in JavaScript engines, how they started to approach native speeds these days.

Back in the day, that was not all how it worked.

It was all interpreted.

It was all very slow.

And then, of course, Douglas Crockford, as we like to say, he discovered that JavaScript has good parts.

And he wrote a book about them.

And so we kind of started to get the inkling that JavaScript was not just this crappy language that we all used for scripting and image rollovers and DHTML, but actually maybe it was a language in its own right that had an existence outside of the browser and outside of something we had to delve into when we could take ourselves away from our beautiful dot NET, and Java, and PHP server.

And so as momentum gathered, we have a new version of JavaScript.

And we have this community led standardization effort, it started out as ServerJS, but they renamed themselves to CommonJS, focusing on things that the language needed, or standard libraries that the language needed.

And a lot of their efforts fell by the wayside.

But, the module system that they created is still with us today in Node, and in some extent in AMD.

And even the unit testing spec that they wrote up, it influences QUnit and the Node.js cert library.

And, of course, in 2009, that was the year that Node.js was announced,

at JSConf EU 2009.

The first time that we really saw JavaScript used on the server in a wide way that-- this was the first time that people had latched onto the asynchronicity of JavaScript on the server.

Before that there were other solutions, but they were all synchronous, they didn't really embrace the JavaScript ethos.

And PhoneGap and, of course, the first JSConf, speaking of community led efforts.

So 2009, I think, was really the first year that JavaScript was starting to explode, starting to kind of gain larger developer mind shares.

Maybe this is the next big thing.

And our client apps got a lot better.

And it's really kind of crazy to think that just three years ago there didn't exist a Backbone and a Require.

If you go back and look at the commit history, that's the first time we had access to these kind of structured ways of creating client side web applications.

Starting to bring, things that in other languages might have been obvious, how to do MVC, and how to do module system to our client side JavaScript development.

And skipping ahead a few years, in Windows 8, when they announced this, it may not be so exciting to all the Mac users in the room.

But it was really exciting because it was the first time that a major corporation said, this is our operating system.

It's going to be based on HTML 5 and JavaScript.

That's how you write your apps.

And then another tack, there's the NodeCopter movement started just last year.

The idea that you could use JavaScript to control AR drones, control copters, in the real world, and we'll talk more about that later.

And this year, of course, we have much more going on.

We have extending onto the hardware, we have NodeBots, and we have Ember and Angular fighting for dominance in the web platform space.

We have the Extensible Web Manifesto, which Angelina mentioned, but it is really exciting because it's saying that JavaScript is the foundation of our platform.

It's how things should be exposed and it's how developers should interact with the platform, and how they should iterate with standards bodies together.

An ASMJS, my personal favorite, a really exciting way of using JavaScript as the byte code of the future.

So looking forward to next year, what are we going to have? We're going to have ES6 finalized by the end of this year.

So we're going to start seeing implementations.

We already see some, but we're going to see them finalized in 2014.

ES7 is on a fast track.

They're going to try and release it after one year of just adding small incremental features.

And, of course, whatever else we come up with.

There's plenty of surprises waiting.

So let's do a quick overview of JS on the front end, because that's Fronteers, we're on the front end here.

And we'll skip through this quickly, but it's worth keeping in mind what the landscape is as kind of an intro to JavaScript in the wider space.

So in the beginning, there was jQuery, of course.

And then we said, MVC, that seems good.

Other languages have figured that one out, so we have Backbone.

And these days, we have Ember and Angular.

And this is really where the action is these days.

So if you're not looking into these frameworks, I would definitely encourage you to do so.

What's interesting is that they take slightly different approaches but they both kind of have recognized, as a foundation, that data binding is the way to go.

So Angular, their slogan is, HTML enhanced for web apps.

And I think this is really telling, because that is what they're doing.

They're saying, create your custom elements, create your directives, create your custom attributes.

We're going to allow you to do all these things to create custom widgets, and that's how you build your web apps.

They don't put the focus on the overall app as much as they put it on the individual components.

And they say, you should build a larger app out of composable little components.

And this is a really good approach for things like trading systems, or dashboards, where you have lots of widgets on one screen.

So Ember, on the other hand, their tag line is a firmware for building ambitious web applications.

So I think the sweet spot for Ember is what I call multi-page, single page, apps.

Where you have multiple screens, or tabs, or areas of your app where you need to navigate.

And what they emphasize is that this all maps down to the URLs.

They say that you give structure to your app by saying, these are the resources that you are going to.

These are the places that you end up.

And so that ties into their model layer, where you pull things from the back end and associate them with URL, and you tie that through with convention over configuration to the views and to the models, and to the data, and that's how you set up your app.

And it all ties together.

They also have a components framework, but their primary focus is on giving you structure, giving you this whole all-encompassing thing.

So that's a pretty interesting contrast, I think, when you're choosing between these frameworks.

It's not like one is a direct competitor of the other as much as they have different overlapping areas where one is more appropriate than the other.

But of course, why let the libraries have all the fun, right? Why should why should we have to use Ember or Angular? Well, as Angelina mentioned, that in detail, we have web components coming up.

So the exciting part here, I think, is custom elements.

Because there's the start of the web platform embracing JavaScript as the extensibility point.

They're saying, oh, we're going to actually have constructable new MyElement.

And you're just going to register that with JavaScript, it's going to have its own prototype chain.

You're going to use normal JavaScript classes.

And that's how you're going to create a Web Component.

And so, in general, well-- web components are all the things we saw, and more, and you can use them in Polymer.

We've been over that.

But Polymer is really cool because it's a polyfill for the future of the web components.

And this word, polyfill, like, probably going to be a polyfill, is a really important one, because this is, these days, how a lot of specs are written, and how a lot of specs come into being.

In this case, it's a well-- Angular was kind of the original polyfill for the custom elements idea for the web components idea.

For saying, this is the something we'd like to have happen.

And now, Polymer is saying, OK well we know exactly what we want to have happen, writing these specs in tandem with this polyfill for how they're going to work.

And this is all part of the underlying, Extensible Web Manifesto philosophy that I, and others, have put together.

The idea that, we want to put the web platform in developers hands.

We want to say, you use JavaScript to prototype the features you want.

Use the Create libraries like Polymer, or like Angular, or like Sizzle, as my favorite example, the idea of using CSS selectors to select DOM elements.

And, eventually, we will get those into the platform, we'll roll those back in throughout the process.

And this is a really good way for developers to get involved in standards, and to get involved in creating these things, is through this Extensible Web philosophy.

All right, so enough about the web platform, right, because JavaScript has gone far beyond that.

What about everything else? Well, obviously, Node.js is the

biggest player in this room.

And I personally prefer this logo for Node.js.

I think it really captures the spirit of Node as kind of this, strap a rocket engine to a turtle, because back when Node started, JavaScript was still in the stage of, meh, JavaScript, who knows, it's this language some people use on the front end.

But Node has really kind of captured the community spirit for how you're going to be developing new things in JavaScript.

This is where we saw modules and binary data, for example, before we saw anything else.

One my favorite stories on that binary data idea is, back when Node started, clearly it's a server, clearly it needs to deal with binary data payloads.

So they'd come up with their own little abstraction.

At the same time, WebGL was starting to take off and it was standardized by the Khronos Group, because they standardized OpenGL.

And so they were the ones who came up with the typed arrays, and their ray buffers, and all that.

And there was some kind of discussion between the people at Node, the original people who sat around and coded all night on Node.

Should we adopt this typed array thing? Should we go with that? Would that be where we go? And from what I hear, Ryan Doll, the original creator of Node got really angry with this discussion at some point.

He was just like, the experts on binary data and JavaScript are in this room, right now.

So we're going to decide what to do.

And if they'd waited, we would've been at a much worser place than Node.

We wouldn't have had a binary data abstraction.

So now typed arrays were starting to settle down.

They were getting incorporated into ES6, formally.

But I think it's kind of telling how Node leads the way on a lot of these things, on a lot of the interfaces that we want.

And this proves true time and time again.

I mean, their prototyping streams and working very hard to get streams into the browser right now.

They are where a lot of the experimentation goes on.

They had a package manager before any of us.

We'll talk more about that later.

That's Node.

And the thing about Node is because it's its own JavaScript runtime.

It took JavaScript out of the browser.

It enabled a lot more use cases.

So if you wanted to control a NodeCopter, a copter with JavaScript, it's as simple as this.

You can have this little [INAUDIBLE] and type these little commands.

It's literally as simple as, take off, do a flip, spin, go forward.

That's all it takes to control something as complicated and crazy as these little copters.

You can make-- and people have written programs to deliver your beer to you with these copters.

Program copters that will take over other copters, and with a virus hive-mind and descend upon the city of New York, maybe not that far.

But we're not that far away from NodeTerminator.

So be scared.

Maybe.

Those Node people are scary sometimes.

But it goes beyond-- Copters is one particular instance of the idea of Node controlling hardware, and controlling the real world.

And here's my really fun example using this library created by Rick Waldron, who originally was on the jQuery core team, or still is.

But this is what he's really into now, is enabling people to control hardware with Node.

So here's a tiny little piece of code, something almost jQuery-esque with a very nice API for controlling the sonar device that you would strap to your Arduino, for example.

So you can control all these kind of appendages, whether they be sonar, or radar, or servos, and all this stuff.

And people have created really impressive NodeBots with this.

Sara Chipps also gives a lot of talks on this.

And my favorite example of hers is that they created a NodeBot that would answer the doorbell for them.

So they could, on their phones, be like, oh yeah, press a button, let that person up.

So the idea the JavaScript can control the real world is pretty powerful.

And it goes even lower level than that.

There's this product called Node SerialPort.

And when I first heard about that, I was like, OK, who uses serial ports anymore? I didn't understand.

Because that's what I think of, this COM1, right.

And so then I thought, that must not be it.

People don't actually use serial ports.

They must be talking about something else.

So that was my next thought, was what is a Node SerialPort? But I quickly, when I asked some people for clarification they pointed out that no, actually, USB is a serial port.

So when people say serial port, they actually mean USB.

And I think Node USB would have made a lot more sense to me, but probably less technically accurate.

But the idea is that you have this really easy way of using JavaScript to control at the very lowest level the devices appended to your computer.

So what we're doing here is we're just writing data out and getting data back in, again using a nice API.

But this can control anything.

So in some sense you can write like a device driver for whatever you want to cook up, whatever you create, or whatever you buy to control it with JavaScript.

So JavaScript really has the ability to reach very deep into the real world.

And the person who creates the Node SerialPort library uses this to create devices for assisted living for old people.

And some other people are you using it for all kinds of crazy stuff, NodeTerminator, as I said.

But that's pretty exciting.

All right moving on to the real world.

Back to, perhaps, the opposite of the real world, is Windows 8.

Again, it was really exciting to see this when it came out.

The idea that we're going to write our apps for this major operating system, which despite the census of the room, still has an extremely large market share.

It's going to transform the way that people write apps.

And a lot of people got very upset, because this was Microsoft essentially dumping Silverlight on the floor.

But they chose us, so I'm not mad.

And building off of that, right, this is a trend.

We have Firefox OS, where everything is built HTML5 JavaScript, even the basic UI elements, the app drawer, things like that.

And Chrome OS, of course, you write your apps as Chrome Apps.

Chrome Apps are kind of anti-webbie because they have all these privileged APIs.

But hopefully we'll fix that with more APIs.

But what's interesting about all of these platforms, these ideas that we're going to write our entire platform in JavaScript, is now you might want to have access to something lower level, something that you might normally not consume in a web page, something like git.

And so, people have actually started doing these kinds of crazy things.

They've put things like git into JavaScript.

So JSgit is a Kickstarter project by Tim Caswell who is active in the Node space but also this crazy wizard experimenter guy.

And so in his Kickstarter funded time, he's essentially writing a git implementation in JavaScript.

And I think this is really exciting because it proves that JavaScript can do anything.

You would think git is out of the scope of JavaScript.

But it's not.

We have all the parameters we need.

We have binary data.

We have HTTP requests.

We have file system access.

We have all of that.

We can do git in JavaScript.

And he's doing it.

And now we can run it on our Windows RT tablets, or our Chromebooks, or our whatever.

We can do git.

No need for even native bindings, right.

There's no C++ in this project at all.

But even before that, things like PDFJS, it proved we can render PDFs in JavaScript.

And if you use Firefox these days, which I still do.

I know when I look at my analytics log 70% of my visitors are using Chrome.

But I still use Firefox.

This is the default PDF renderer.

It's a PDF renderer written in JavaScript.

And so it proves that with the power of things like Canvas, which kind of gives low level access to the screen, you can render whatever you want, pixel perfect PDFs.

And this is pretty exciting.

But even more exciting is this new project that just got turned on in Firefox Nightly recently called Shumway.

And Shumway is an implementation of the entire flash VM in JavaScript.

So, yeah.

So this is pretty impressive because you take all of this ActionScript code written in an entirely different language and you take out the byte code from the SWF file, and you transform it into JavaScript that you can run in your Firefox, using Canvas and using all these APIs.

And it actually works.

People are running Candy Crush at higher numbers of frames per second in Firefox, with the Firefox Nightly with Shumway.

So JavaScript is swallowing everything is, I guess, the moral here.

So one big thing to make JavaScript swallow everything is the notion of ecosystem, the notion of platform, the notion of sharing.

And writing code that is reusable for other people.

And composing code out of code created originally by other people.

And I think the answer to this is in NPM, which stands for JavaScript package manager.

The thing about package managers is they're based on network effects.

And it's important when you're creating a package manager, and when you are entering an ecosystem, and when writing code to share with other people that you don't restrict yourself to one segment of the audience.

You don't say, I'm only for browsers, or I'm only for people who use this.

So if you silo yourself into a JamJS, or Bower, or Component1, or Volo, or whatever, you're saying, essentially, I don't want to participate in the wider JavaScript package management ecosystem.

So NPM is where all of the code goes.

That's where you should put your things.

And most of the packages on NPM actually work in the browser with the help of something called Browserify, which adds basic support for things like event emitters, and things like that to the browser, and even HGP if you have XML HTTP request or file system via Chrome's file system API.

So this makes it very easy to create code that builds on top of other people's code.

And you can kind of see this because if you look at the dependency graph for NPM it's pretty massive.

People are depending on each other's code in an amazingly complex and multivariate graph.

And so the biggest package, the most depended upon package in all of NPM is Underscore, which very clearly works on both client and server.

Most of these do as well.

Even things like Request, which makes XML HTTP requests when using the browser.

So this is the ecosystem that you want to be part of, not the 200 package ecosystem of those other competitor package managers.

You want to take part in this large network of growing code so that you can build on top of other people's things and they can build on top of you.

And a good example of this, I think, is the Voxel JS project which, if you've seen it, is basically Minecraft in the browser.

Now, again, one of these crazy JavaScript can do everything things.

So it uses WebGL, it uses all these web technologies.

And what's cool is that they've built it out of a series of composed modules.

So if you want to just use the core game engine, you can use that.

Or if you just want to have something that will render textures from texture files onto WebGL surfaces, you can use that.

Or if you want something that just does requestAnimationFrame polyfill, you can use that.

It all comes together in this large dependency graph that builds into Minecraft in the browser.

And people can take those apart and create little packages that are plug-ins, or create other game engines that build on top of these.

This is the ecosystem that allows JavaScript to thrive.

So there's that.

All right, for the technical stuff, to close us off.

JS the language, right.

This is what a lot of you on Twitter want to hear about.

Stopping off, before we get to the ES6 stuff, shout out, again, to asm.js.

In case you weren't aware, the idea of asm.js

is to take a subset of JavaScript.

To say, JavaScript has bitwise operators, and typed arrays to create large blocks of memory that don't get garbage collected.

And it has integer multiplication with a new edition of the standard math.imul.

And it allows you to compile higher level languages like C++, or anything else, down to JavaScript, down to the subset of JavaScript.

And this subset is extremely well optimized by today's VMs.

And Mozilla has put in some work to make it even more optimized via this ahead-of-time compilation.

That's really what asm.js is about.

But it performs very well in all the browsers.

And Chrome is pursuing a strategy where they don't use ahead-of-time compilation, where they just optimize it anyway.

And everybody wishes them luck on that.

Brendan Eich is skeptical.

I'm hopeful.

I don't know anything about it so I can't really judge feasibility.

But it's really exciting that we're going to just take C++ and shove it at the browser and say, here, run it.

And this allows you to do things like take all the games that have been created.

Nobody's going to rewrite, Knights of the old Republic, one of my favorite Star Wars games.

Nobody is going to rewrite that in JavaScript.

But they can compile it with asm.js

and run that in the browser.

And now you can play, be a Jedi in a Galaxy far, far away in JavaScript, in your browser.

And this all ties into the theme of JS as the assembly of the web.

That's kind of interesting because it's like what you would hand right, sometimes, if you were really hard core, but also as the VM of the web.

The idea that you could write whatever language you want and it'll compile down to JavaScript.

And it will be the foundation.

And we won't need any of this kind of byte code.

And there's some really good arguments.

Brendan Eich gets on arguments on Hacker News.

Love him for it.

Very fun to read.

Where he tells you exactly why a VM, a byte code, the agnostic byte code is not the way to go.

That JavaScript is the byte code and the VM on the web.

So, again, JavaScript is going to swallow all of these other languages.

All those things.

And there's compilers for all of these to JavaScript.

You can look up Jeremy Ashkenas maintains a big page full of all the different things that compile to JavaScript.

And all of these are on there.

So you can write any of these, even if you like Haskell.

If you're one of those people, you can write that in the browser today.

Of course, the original compile to JS language, not the original, but the most prominent is CoffeeScript.

And CoffeeScript is really cool.

And I got really into it for a while.

But there's something even better coming along in terms of transpiled languages, and that's ES6.

And the main transpiler for ES6, for the next version of JavaScript to the current version of JavaScript, is called Traceur.

Traceur doesn't have a logo.

So I made it one.

It turns out that if you look up traceur on Google Images, and actually in the dictionary, it's a guy who does Parkour which is this acrobatic urban thing.

So that's now the Traceur logo.

You're welcome, Erik Arvidsson.

And it's kind of kicking away the coffee cup, because it's better.

Yeah, we can leave that out of the official logo.

Anyway, the best way to use Traceur, I think, is this browserify transform called ES6ify, which is great because browserify has all the infrastructure for bundling and source maps and all that built into it.

So here's an example, and I think it's big enough to see, where we're using ES6 classes, in the browser, stepping through them in the Chrome debugger, using all these features, Super, and so on and so forth.

And you can use everything, there's this class syntax with Methods and so on.

But you can use arrow functions and generators, and all the fun sugar that we'll talk about momentarily.

So, yeah, ES6, you can use it today.

But what is ES6? What is the point of ES6? The biggest point, I think, is to not stagnate our language.

If we stagnate in one place, we get in the situation HTML was in 1999, where we're sitting still waiting for SPF, and Silverlight, and so on to come and eat our lunch, and Flash, may it rest in peace.

But we need to keep up with the times.

we need to create a productive language for developers, something that people will really enjoy programming in, and be able to create powerful abstractions in for the next level.

And this is summarized in the official goals of the TC39 Standards Committee, which is to be better for applications and for libraries, including the DOM, they want to be able to explain the entire DOM in JavaScript, instead of this crazy C++ JS IDL land, or Web IDL land.

And, of course, code generators.

So we want to be able to make asm.js and anything else

as fast as possible.

So what's new in ES6 anyway? So let's go over some of these things, in turn, because I think people generally enjoy finding out about these if you haven't already.

So starting out easy, on the syntactic level.

So we have Class Sugar, we have Class and Extends, and Super.

I want to emphasize this is just Sugar, this is already JavaScript's prototypal inheritance models, the things we do today.

But you don't have to use any of those stupid libraries where they're dot extend, blah blah blah, Favorite, Super, Simple, Class library for JavaScript number 3,000.

You can just use what's built into the language and it'll de-Sugar it for you into these patterns that we're used to.

Arrow functions, easy win.

Notable that they have lexically scoped this.

So they're like CoffeeScript's fat arrow functions.

They preserve the disk from the outer scope.

There was talk of adding a thin arrow function, but it was said that that was one arrow too far, and I somewhat agree.

De-structuring, this is a pretty simple one at first glance, but it's actually really neat at second glance.

Because the idea is, instead of creating a temporary variable and pulling off properties.

You can directly assign variables to the properties.

But, this has some interesting aspects.

First, I think it'll change the way we code.

Because it makes multiple return values really idiomatic, really easy to create, and really easy to consume.

And second, because it's really optimizable.

So let's say, Get Point was actually an XYZ point, three dimensions.

Well if you see on the call site that they're actually only using the x and y, the compiler can say, oh, I don't need to allocate any space for the z.

And in fact, I don't need to do any of those computations for the z, as long as they don't have side effects and I can throw that out.

So makes your code nice and optimizable for the compiler.

So it's a good target for the language to add.

Rest and Spread, easy wins.

We can finally stop messing around with Slice, and Splice, and array dot prototype dot slice dot call to get the arguments.

This essentially obsolete the arguments array, entirely.

So we no longer have to use that stupid thing.

We can just use dot dot dot everything will be handled.

And final, kind of syntacticly I'm going to talk about is parameter defaults.

This is a fun feature because it's actually a lot more complicated than you think, because you can put anything on the right hand side of the equal sign.

So, for example, I can put X on right hand side referring to an earlier parameter.

I think it's really complicated.

And you can even put expression statements on the right hand side that would modify variables, or modify other parameters.

And so this is why this feature actually is still undergoing some spec turn.

But in the basic case, it's just going to make your life easier.

And in the hard case, it's going to be a good source of brain teasers for the next few years.

Next major set of ES6 features is the data structures.

And some of these are just Sugar and some of them are more general parts of the language.

So Map is the first time we've been able to actually do an object-to-object map with O1 access time.

You can simulate Map today, but you can't really do it efficiently.

You can't say, I'm going to have Object as my Keys and I'm going to have O1 access time.

You can maintain two parallel arrays but that doesn't have good performance characteristics.

So that's going to enable a lot of use cases.

And Set, of course, is just a specialization of this, the idea that you can do O1 look-up.

There's some really fun code that allows you to unique-ise an array much faster than you were previously able to do with a simple syntax.

So it's just like, create a set, turn it into an array, very easy.

And WeakMap and WeakSet, these are interesting because they're not named very well.

They're named for what they are but not for what you'll use them for.

So, you'd think like WeakMap and WeakSet, oh that's just like a worse version of Map and Set.

I'll won't use those.

I'll use the strong Map and the strong Set.

But, actually, so WeakMap, the idea, is you put an object as a key, and you put other stuff as the value, and then you can look that stuff up.

But it doesn't hold on to the key for garbage collection.

Because if you put an object in a data structure, say, an array today, it's going to hold a reference to that.

But if you put in a WeakMap, it won't.

So what this allows you to do is put private state on objects, both your own objects and other people's objects, and then look it up later.

So an easy example of this is jQuery's data property, which has its own kind of semantics, needs to get cleaned up from the DOM, that's why you have to call Remove all the time.

This will just make that automatically work.

But it's also the essential way of doing private state in JavaScript while still staying in the prototype model.

Because, if you remember, if you ever tried to private state, you essentially get forced into the closure pattern, which makes you allocate a new copy of each method for every time that you create the object, just to have access to the state you stored in the closure.

With WeakMaps you have true privacy without the expense of the prototype, just by keeping the WeakMap inaccessible and making it only accessible to the prototype.

WeakSet is, again, it's a little specialization of WeakMap, you can easily make it in terms of that.

But they use here is for something called Branding.

And what this means is essentially checking that an object is of the type that you want it to be.

So the idea here is you're writing something like the DOM, and somebody calls append child with some random thing.

And you want to make sure that that's actually an element, and not just something pretending to be an element by having three or four properties that make it look like an element.

Well the way that you'd use WeakSet to accomplish this, is every time you create an element you would put it in the WeakSet.

And since it's weak, it wouldn't hold onto it, it wouldn't keep a reference to it that prevents garbage collection.

But this means that later, when somebody passes you in the element, the possible element, you check, is it in the WeakSet? Yes.

OK, it's a real element, Go.

If not, then, no, don't let it through.

It's going to mess up and cause crashes because C++ isn't equipped to deal with it.

So that's a pretty nice set of features at the low level.

The Iteration Protocol.

So it's, the for-of loop is the new way of iterating over everything.

Over arrays, maps, sets, even user-created objects, there's a simple hook that you can create that allows you to return an iterator, that allows you to iterate over your own data structures.

So if you want to create a breadth first tree, with its own little iteration protocol, you can do that now, and everybody knows you just consume it with for-of.

And this kind of exemplifies how ES6 works, and the web, in general, works.

We can't take out old broken things, or change them, like for-in.

We just add new things and hope that you forget about the old one forever, never use for-in, ever.

So that's a nice unification.

Finally, in data structures, Typed Objects.

The idea here is to provide a compilation target for things like C#, or Java, where they say, oh, I have a field, a struct, that has these fields of this type.

And you build structs up from other structs, or from the primordial binary data types, of, like, uint or just int.

And this will allow really compact, memory efficient, garbage collection friendly, representations of primordial types for games, is a good example of this, but also transpilers.

All right, so, finally, the game changers.

What are the new things in ES6 that are really going to change how JavaScript works, how we write JavaScript? Well first, of course, is generators.

And you may have seen some articles on this.

And they're good for two things.

First, is lazy sequences.

So all those array methods that you like to use, that you end up feeling bad about, because you're, like, oh, I filtered and then I mapped, so I made two loops through the array.

That's bad.

I should probably go back to using a for loop.

Well with generators, you don't have to do that.

You can have the sequence be lazily produced, lazily consumed, lazily transformed.

And at the end, when it's time to actually use it, that's when those things get applied.

So this is going to be really interesting for collection libraries.

The other thing that they can allow you to do, and this is where they've been getting a lot of attention, especially in the NodeJS space, is they can allow you to do an async await type syntax, if you're used to that from C#, or from other languages.

The idea is that you use the generators which pause execution flow.

And you say, oh, wait until this promise fulfills or rejects, and then come back.

And if the promise rejects, then throw an error.

And we can handle the asynchronous error with Try Catch Finally.

And if the promise fulfills, then we just get the value and we put it in this variable.

And then you can use it like you would a normal synchronous control flow.

So this kind of brings some sanity back to JavaScript's asynchronous programming.

No more callback hell.

No more crazy combinator functions.

Just puts everything on the same footing as your normal things.

You can do a for loop, and then put async operations in the middle, for example.

It's a big deal.

Promises, of course, go along well with generators.

They're the idea that we're going to standardize the asynchronous pattern that's been used in pretty much every client side library for the last five years.

And we're going to put it in the language.

It's going to be standard.

I took a bus up to Boston, and presented the spec, and they were, like, looks good.

So now it's ES6.

One thing that doesn't get a lot of attention is subclassible built-ins.

So this is kind of a subtle feature.

But the idea is that they've made some under the hood changes to how objects are created and allocated that allow you to derive subclasses of arrays, dates, regular expressions, and all that stuff, maps and sets.

And it'll have access to the same kind of private internal state.

Because if you try and do this right now, data's the most obvious example, it'll just say, cannot call method, undefined thingy, doesn't have internal date state.

But now it will work because of these changes they've made.

And arrays, you can get your own subclass of array with the magic length behavior, which you can't do right now.

Regular Expressions, of course, you can make your extended regular expressions that inherit all of the behavior of regular expressions without having to rebuild it from scratch.

All right, proxies, virtual objects.

The idea is that you can respond to anything that the language does to you.

It's called the Meta Object protocol.

Whether it be a get of a property, or a set of a property, or a call of a method, or any of that, even in getting prototypes.

And you can intercept it and do whatever you want.

And my favorite example of why this will be useful is we won't have to do the stupid get and set that you see in Backbone and Ember, and makes it just a horrible travesty of JavaScript.

It's like, let's go to this other meta level where properties are represented by strings, but not normal JavaScript strings for properties, just our own little strings for properties.

We'll just have virtual objects that transparently take care of that for you and allow you to bypass all of that headache.

So that's pretty exciting.

You can also have, no such method type things.

And actually a really interesting example of that is remote objects.

So proxies for remote objects.

The idea is that, you create a proxy that whatever happens to it, you just record it, and you return another proxy.

So then you record what happens to that proxy.

And, eventually, you have some terminator, like, OK, wait for the result. And

what happens at that point, is you take all those things you recorded, you send them over the wire to some other computer, say, hey, they want the property of this object and they want to call a method on it, and then they want to get a property of that result.

And then you send that back to the original computer, perhaps as a promise.

So proxies will allow you to transparently do that kind of thing, or almost transparency, as long as you have that little terminator.

So that's a pretty exciting use case for proxies that I don't think has gotten a lot of attention.

But I think people will really start exploring once they start changing the game.

Template strings, another personal favorite.

The idea is, not only will we finally get stupid multi-line strings and no more escapes inside our things, we'll be able to add these little functions in the beginning.

So this is an example that JSX, which is Facebook's proprietary extension, or custom extension to JavaScript, for putting HTML in JavaScript.

Well you can just do that with standard JavaScript now.

And what's interesting about these is these functions get enough data, like JSX is just a function, that they can intelligently figure out what to do when it sees these escapes.

So it can say, oh, I see that I need to insert the URL parameters here, but I'm in the middle of an href.

So let me attribute escape that.

So any quotes, don't do XSS.

Or, oh, I'm in the middle of a text, or I'm in the middle of a tag right here, so let me HTML escape that, that so people can't put things inside of it.

So contextual auto escaping of this sort allows pretty powerful applications.

And finally, the last ES6 feature, modules.

And the big benefit of these is just, we won't have to have the stupid module debate anymore.

The specs been iterated on.

Yeah, the specs been iterated on.

It's gotten a lot better since it started out, if you've ever looked it up and gotten mad.

It's in a pretty good place now.

It has a really nice pipeline.

And finally, we won't have to worry about stupid module format wars.

All right, final set of things, ES7.

Clearly better than ES6, because seven is one more than six.

What could possibly becoming in ES7? Well, we don't really know for sure.

But these are just some of the whispers that I've picked up by paying close attention to mailing lists.

So WeakReferences, it turns out WeakMaps and WeakReferences are orthogonal, you cannot build one on top of the other, either way.

So this allows you to do things like, say, oh I'm holding onto this object weakly because I'm going to data bind it, or something like that.

And it will automatically, if it gets garbage collected, then you'll have to say, oh, is it null? If so, don't do that.

If not, then it's not garbage collected yet.

This is pretty tricky to work out because garbage collection is not something you want to expose to the user directly.

Otherwise, they'll start writing code that only works in Chrome's garbage collector, for example.

But they kind of figured out a nice trick to make it work.

So that will probably be coming ES7.

And building off of the generators and promises theme from ES6, there's some hope of making a syntax to make it even better, even nicer.

Because generators, you need this little wrapper function to transition into generator land.

So this is one possible syntax being floated around.

We don't really know, nobody really knows, what exactly it's going to look like.

But this is one idea, if people want to write transpilers to prototype things that would be much appreciated if we get some idea of what people really enjoy.

Object dot observe.

So this is the other half of the data mining story for the client side.

But, also, it allows you to do general JavaScript object observation.

It is whenever an object changes you will be notified of it at the end of the next turn.

You'll be able to react to that appropriately.

So this allows you to then go update the DOM, or if you have a computed property, be able to go update that computed property, things like that.

And then what's cool is that there's no overhead as long as nothing happens.

It doesn't actually slow down your app.

There's no dirty checking overhead like there is in Angular where every time somebody clicks, or p presses, they have to go traverse the entire object graph to see if anything changed.

So there were some really nice graphs at the last [INAUDIBLE] meeting that you can check out to see how much faster it is than Angular's technique.

Value types, a personal favorite of Brendan Eich, is that finally we'll have stupid integers in JavaScript.

So, yeah.

We'll be able to create our own as well.

And he has this really cool value class syntax he's been floating around with user defined operator overloading.

So you'll be able to say, complex number plus complex number equals other complex number.

And there's some tentative ideas for literal syntax.

So you can do L as a suffix, and get a long integer, things like that.

And you'll be able override all these things so you can say this URL is equal to this URL with the double equals operator.

No overriding triple equals, which is a bit of a shame, but also understandable.

Because if they're actually different objects, yeah.

All right, last thing.

This is just a personal, like, everybody wants this stupid bind operator.

This is shorthand for object [INAUDIBLE] bind object.

I think this makes it a lot more transparent, how you pull things out of objects in JavaScript.

And everybody kind of likes this.

And it just hasn't had the time to spec it.

So hopefully we'll get that little tiny thing into ES7.

And that's it.

Yeah, JavaScript.

[APPLAUSE] I'm really excited about this virtual objects.

Yeah.

That is so legit.

There's always like that challenge of like you want to-- I was thinking of that situation where events are coming in, let's say, you've got, like, JavaScript running the page but you don't really want to act on that yet.

Right.

You just want to kind of capture all those calls as they come in.

And then, at some point, when the rest of your pages are ready.

The, you're like, OK, OK, well we'll hit on that now.

Exactly.

It's like, yes, please.

Cool that is fantastic stuff.

Really excited.

Someone was actually asking about streams.

Node has done a lot of work in streams, had a bunch of iterations, what about streams in kind of the browser? Yeah.

No.

So this is something I'm very interested in and working on.

So there is a streams API that you should not look up because it will make you cry.

It's very bad.

And nobody wants to implement it besides maybe the guys who wrote it.

But I think they're invited experts, so they're not implementers, so we're safe.

What we need to do is take the lessons that Node has learned, and not necessarily copy them, because they made some mistakes along the way, but figure out what the correct streams API is for the browser.

And this will enable really cool things like streaming HP downloads and then you pipe that into a image tag.

Or you pipe it through a web worker which does some transforms on it and then you pipe that out of the web worker into a video tag.

Things like that.

This is clearly something we need.

There's this great slide by Max Ogden, that shows like 40 different browser APIs that are kind of streams.

And then on Node, they have just one.

So we need to unify all these primitives.

And I'm working on it.

It's my next big thing after Promises.

We have some buy in from some implementers.

But it's all very early stages.

So if you get involved, let us know.

All right, so that's great.

As for availability, ES6.

How available is it in browsers? So Traceur is really awesome.

I do want to emphasize.

It has a few features that don't transpile very well, that add a lot of overhead when you use.

But a lot of the more basic stuff, or the more syntactic sugar stuff, worked out great.

And you should definitely use that.

Firefox has been implementing these things pretty rapidly, and not even under a flag.

Which is great.

So if you use Firefox, or Firefox OS, you can just program with WeakMaps, and arrow functions, and various other crazy things, right away.

Chrome has a few things under flags.

They have generators, which is a big deal.

And sadly it had to be implemented by Bloomberg instead of the Chrome team, but I guess that's Open Source goes, priorities and stuff like that.

So Chrome still has flags.

IE, actually I forgot about this, IE 11 has implemented a few features.

It's implemented the new data types, including WeakMap.

And it's implemented Let and Const, which I didn't mention.

So it's coming.

Use Traceur.

Use Firefox.

If you're in Node, just run with dash dash Harmony.

Nice.

I was wondering if you could tell us a little bit about Object Observe.

Was it originally targeted for ES6, and then it got moved to ES7? No it was always ES7.

Because they had a pretty good idea of what they wanted in ES6.

And it's really just been kind of tightening down the hatches on that for the last year.

Tightening them way down.

And then, you're like, except for that whole Promises thing.

Let's just sneak that in here.

Yeah.

So it turns out when you write a really detailed spec with like everything worked out, then they're pretty much, like, oh well, OK.

OK.

Also it really helps the module loader API suck less, because it can return Promises instead of using Callbacks.

Yes.

That's one big reason.

Object Observe is part of the new ES7 release train, which is just put features out there as fast as you can and when the year rolls around, and it's time for you to go to the ECMA General Assembly.

Say, OK, that's it, that's ES7.

This is the proposal from Rafael Weinstein? Yes.

Yeah, Rafael Weinstein had this proposal.

And everybody pretty much likes it, where it's a more iterative process where champions of these different features just put their things out there sooner, and do their own spec text, and get it incorporated.

And once a year, they just ship a version.

It's no more of this monolithic, work on it for four years-- It's kind of more like the every six week release cycle of Chrome and Firefox.

Right.

It's just let's apply it to standards instead.

But languages are a little bit more complicated than browsers.

Yeah.

Yeah.

I'm really excited about that the kind of like pace.

I think it's going to avoid some of this issue that we have with ES6, kind of taking the time.

Yeah, it's been taking a while.

Will Node be able to get rid of the Require syntax? And are there conversations around moving over to the new module? Yeah.

This is kind of controversial, because the Node people are very stubborn, very set in their ways.

Some more than others, though.

And I think there are some important, and influential, Node people who recognize that you can't did your head in the sand and avoid the future forever.

So their policy is very much when things land in V8, not under a flag, then we'll deal with them.

So that's not going to happen for a little bit of time.

But once it does, then I think they're going to say, OK, well somebody else do the work for us.

And then we're like, OK, that looks good, put it in Core.

And this is kind of a crazy idea, but one of the things they're contemplating is because they've been working on Node for so long, they have the rewrite bug.

They're like, ah, we just could have done everything so much better.

But we can't break backwards compatibility, that would be bad.

So what if, when you did import HTTP you got Node 2 HTTP? And when you did Require HTTP, you got Node 1? So they're even kind of excited about ES6 models from that perspective.

But that's a crazy idea.

It's not official policy in anyway.

It's just something they're floating around.

Yeah, that's cool.

All right, well thank you very much, Domenic.

This was great.

Cool