 Good morning. Nobody's hung over, right? OK, cool. So you can talk about some classes, then. We can get it down and dirty with some code, and we can tear into some really interesting stuff. So I'm going to talk about aligning Ember with web standards. My name is Matthew Beal. I go by MixOnic, and I work with a great consulting firm called 2Increated. We're really just three people, but we do wonderful Ember work, and we're really proud of it. So I want to dive straight in, because we've got a lot to try and go through in a little bit of time. So the JavaScript standardization process is something that we've thrown out a lot of names for. We have ES6, we have ES7, ES2015 has come around, and I'm pretty sure all this highlights a change in the way that we're standardizing JavaScript. Now, this is super exciting, but it is really important context when we think about how we work with new JavaScript features today and how we're going to be working with them in the future. These colors are going to be really popular on slides for the next year, so get used to them. There are two major standards groups that we need to think about when we're talking about web applications. And the first one, the WD and W3C, they focus on things that are HTML-ish things, so stuff like DOM, things like XHR, they deal with a couple of things that aren't strictly DOM like streams, but for most part, they're restricted to things that are browser APIs. The second group is TC39, and they work with ECMO International to standardize JavaScript itself. They work on things like classes, for, if, let, like things that are more syntactical and broad language features that you would see in Node or IOJS, something like that. But there's a different way that you can slice these, and this is kind of what I want to talk about, because this is where the big shift is happening. The WG and TC39 are working groups. So working groups are tasked with the job of coming up with a proposal for a spec and then submitting that spec to the standards group. So they're the ones who actually have to do the hard work of getting consensus around different ideas and maturing those ideas, getting those ideas to be experimented on in the wild and implemented in browsers in the wild, so we can all try them before they really become solid standards. In 2008, the WG was given the task of creating HTML5, and they worked on it for a few years. 2011 came around, they said, great, I'm gonna go ahead and we're ready to standardize this thing, and they realized they weren't done. They realized that HTML would never be done. And so the idea of releasing a one-time standard and then starting all over again was really exhausting. So instead they said that they'd move to a new development model where the technology is version. We have a living document, and this was kind of like a revolutionary idea that we would have a living standard for something. So instead of having a strict thing where you adhere to this document, we have a document that the WG can increment over time and make changes to. If we look at JavaScript, TC39 and ECMAScript International, they have their own storied, varied history. ES3 is the version of JavaScript that we use in IE8. If you support IE8, and Ember still supports, but besides that, you're not really gonna interact with it anymore. There was an attempt to create ES4, and ES4 is actually a lot of the ideas that we're looking at today in ECMAScript 2015 were part of ES4, but they couldn't gain consensus because it's a big process with a lot of people and it's one version, so you all have to be aligned when you make this decision, so it just failed. So they threw it away, and then a few years later after they realized that JavaScript wasn't dead and the Web 2.0 was booming, they came up with ES5, which was really compromised. It was let's just throw all the things that we can on the raft and we'll survive for now. And so we started working on ES6, which was going to be yet another giant release, right? Like all these things, but that's been kind of nuked. And instead we have ES2015. And the idea of moving from a giant hovercraft to sailboats here is that the change in the process is that we're gonna focus more on individual features, and we're gonna focus less on having a huge big bang release with all this stuff built into JavaScript. So this is like a big change in JavaScript, right? And this means that HTML and JavaScript are gonna kind of work better together and both focus on features. This is the list of features that you can go on to GitHub and you can see what TC39 is working on. And you can see they all have on the right hand side a stage. So the idea here is all these standards, all these individual features will move through these five stages, and as they go through them they'll actually be used in the wild. So as soon as something gets to a proposal you should be able to try it out if you wanna try it out. By the time it gets to be a draft you can probably maybe use it in Babel behind an experimental flag or in a browser behind an experimental flag. Candidate means it's out there and you can really use it. And by the time we get to four it means it's done in shipping. And then the aim is that when we get to ECMAScript 2015, 2016, 2017 we'll just be able to say what features are stage four and bundle them up, hand them off. And that's very similar to what happens with HTML5 where the living standard is changed all the time and when W3C, the standards organization wants to release a version what WG says, go ahead, snapshot the document, release five. And that's exactly what they're doing. There's an HTML5, a 5.1, a 5.2 and they're gonna come out over two year increments. JavaScript looks like it'll come out maybe every year. So we'll have the 2015, 2016 snapshot. And so this is kind of new that we have this across the board living thing, right? We think right now about stuff like, many of you use Babel and we're gonna talk about Babel but it used to be called six to five, right? Because it compiled down to ECMAScript five. We're gonna be iterating more in the future and these features are gonna kind of be churning under us on the platform. So we need to figure out a way to live with this. So this is not gonna be a one-time event. The idea that we align with ECMAScript six is not gonna happen once. It's gonna be ongoing and it's not gonna be free. There is gonna be pain. So I think it's worth taking just a moment to talk about why we use standards especially in Ember and why we're so serious about using them in the framework and getting you guys to use them in applications. And the goal is really productivity which is the watchword and like the key value that Ember is trying to bring to you. Standards have a couple really important benefits. They're especially for you guys as developers and productive developers, they're portable. So if you build an Ember application and you learn how to use ES6 modules when you start working on a React application or an Angular application and it uses ES6 modules, you're gonna already have this knowledge. This is not new knowledge, you don't need to retrain every time you change to a new framework or something like that. They obviously reflect best practices because this is something that has been hammered on to gain consensus on from a lot of different parties. There's a lot of input going into it and a lot of making sure that it will be something that we can all live with and work with for a long time. And they will endure. In 10 years, if you're writing JavaScript, you will be using modules. This is not something that you're gonna have to throw away this knowledge. You can actually build your own career and productivity on this and not constantly be churning and learning new things. And these are why in Ember we're very serious about trying to get standards into the code base and into your code bases instead of doing one-off custom syntaxes and custom APIs. The second thing is that participants win. So when we work with standards like this, when we do adopt them early, we get an opportunity to provide feedback to the standards and actually influence them. Modules are a great example. Promises are an example of some place where Ember picked them up early and was able to actually submit information back upstream to let them know what was working and not working. There's a life cycle here and Ember and your applications are at the loving center of it. So transpilers are a new tool, right? This isn't the first time we've had to move in between versions of JavaScript though. We already in the past went from like ES3 to ES5 and when HTML5 came out, this was another time when we had to add a whole bunch of features to the language and work with a bunch of new APIs that maybe weren't supported on older platforms. And Remy Sharpe came up with this idea of polyfill, which he likes to say was rooted in the Greek, but also admits was influenced by a spackle. And the idea was that there was holes in your platform of ES3 or of HTML4 and you want to fill up those holes with little things that behave that fill that gap. So if you're going to work with local storage, you want to create a local storage API that behaves like the real API. And moving from ES5 to ES2015 has been a little bit different, right? We have some things that we can use that same strategy with, but let's take a look. There's a new API for maps and maps is a class. It acts like an object and it's pretty straight ahead. We can go ahead and polyfill that one and we do. We have a polyfill in Ember. We have promises and promises are yet another thing that we can also polyfill. So this is great. The strategy is working pretty well. ES6 has proxies and the way the proxy works here is you have a get and if you ever access any of the properties, like whatever there, it'll go through get and you'll have the opportunity to do a little bit of work, log access or something. And this is impossible to polyfill. There's no way for us to do like an unknown property on JavaScript objects. So polyfills are not going to service well here. And the second thing is like this fat arrow syntax on line four, this is not going to be polyfilled because it's a brand new syntax, right? It's a parsing error. So a runtime polyfill isn't going to be sufficient. We're going to have to use a different strategy. And this is where Babel comes in, which is not news to many of you, but Babel is, in case you haven't used it before, is a tool that takes your ES6, ES2015 new JavaScript code and turns it into ES5 old JavaScript code without you needing to worry about too many details. It looks like this when you actually use it. It'll take like a fat arrow function and turn it into some code that changes the context of this. And it enables us to do a couple new things, new syntaxes, which are greats. It enables us to use some API polyfills. It comes with some API polyfills, but it doesn't help us do everything, but it helps us do a lot of the new features in ES6, which is really incredibly useful and very different from the last time that we had to do this. So they changed the name from six to five. And when they did, James wrote a blog post and he said that Babel was not born to die, was his phrase. And I'm not quite sure he knew how true that was. If you go look at this ES6 table, this is a table of what browsers support what ES6 features. So for six to five to die, everything would have to be all the way up to date with ES6, right? That also means we wouldn't have any new features coming in. So we're gonna have this constant churn. I want to take a minute to look at how this breaks down. There's a feature called UNA array, which is often used for Canvas. So it's actually been around for a long time. This exists in ES6 features. So this doesn't even need to be part of Babel. Babel doesn't even need to worry about this because it's already there for you. It's been there for a really long time. So they're already omitting some things that are technically part of ES6. Something like the spread operator is something that they do process for you, but it actually works if you use it in Firefox. So in Firefox, you're shipping this polyfill that you really don't need. You're shipping this transpilation that you don't need. Block level function scope is another thing and of course this is the opposite and it only works in Chrome. So we've got, sometimes we're shipping code to Chrome that doesn't need sometimes to Firefox and sometimes to IE. And so the surface that we're working on is inconsistent, right? It's not as simple as saying a transpile ES6 to ES5. It's actually much more complicated. Babel has its set of features, Chrome has its set, Firefox has its set. And if you bring in other browsers, this quickly turns into some kind of multi-dimensional, spatial string theory intersection of what features you actually want to transpile and send down. So what I hope we can do more in the future with Babel is get a more flexible tool where we can focus on what features are actually being transpiled. You can do this now. Today there's like a blacklist that you can say I don't want these features to be transpiled. So you'd be able to say I'm only going to use Chrome, which I would not suggest you do. So I don't need this certain feature and I can leave this out and not ship that code down to the browser. I think a mapping to platforms would be simpler to think about. You should be able to say I want to support the last two modern browsers and it'll just take care of throwing away the things that you'd actually don't need to transpile in. In two years, you'll probably be using Babel, right? This seems reasonable. You'll have some code bases that use it. And even in like five years, maybe, will you be using Babel? You think you'll still be transpiling? Do you think that with the continuing addition of features, you'll be using it in 10 years? I think this tool is gonna be around for a really, really long time and that it's gonna be an important tool and that we should continue to put effort into it and encourage Babel to get better and contribute things back upstream as we need them to work in Ember. So the third thing to touch on is Ember's object model. So there are some specific APIs as we go ahead and move things in Ember that go into ES6. We try and not just pick everything that goes into a spec or goes into a draft. We have a little bit of criteria. We want to know that it's stable that the spec isn't going to churn. So a lot of you use modules. We weighed a little bit with modules, but you still felt, for those of you who adopted them early, like churn in the syntax, and it'd be nice if we can get things before they're too early, but it's a balancing act because you also want to be able to submit feedback upstream. We want to know that it's actually a good pattern, something that's useful that solves the problem well. A good example might be Object Observe, which originally looked like it was gonna solve all of our problems and then the more that people worked on it, we realized maybe that's actually not the most ideal pattern. It's not going to solve all of our problems so we haven't done a lot of work with it. I want to make sure that they're actually implemented correctly and performantly, that there's not inconsistent bugs in it across different platforms and that the implementations are fast. An example might be Weakmap. Weakmap is a great new feature in ES6, but was very slow in some browsers. And so it's something that we really couldn't embrace just because the implementations weren't quite up to speed yet. And what I want to talk about is ECMAScript classes. And I'm gonna call them ECMAScript classes and I think this is actually a good way to think about these things. They're not ECMAScript 2015 classes or ES6 classes. They are just part of JavaScript and we should just start talking about them as if they are part of JavaScript. There are really four or three things that go into classes in JavaScript and we're gonna go through some of these features in case you guys haven't looked at them in detail before. So here's a class, has a constructor on line two, has a two string on line six. We have no commas. We have these scoped short syntax functions and it's nice syntax. We can go and create it. We can call it two string and it works. That's a pretty simple example of a class. If we use extends, then we have a constructor. You just extend the vehicle. Vehicle there can either be a class or a vehicle can be a traditional ES5 class which some of you have made before where you have a function for a constructor and you add methods onto the prototype. Definitely compatible. Or it can be an actual object. It can just be a bare object. And then we can use that. Super is, yeah, super syntax is used here. So in the subclass, we want to call the two string of our parents. And you notice that we call super which identifies like the target for all of these different methods. It identifies the methods that are upstream for you. You can delegate to that. In constructors, it's a little bit different though. In constructors, you call super as if it was a function which kind of makes sense if you're used to ES5 classes where you have a function for constructor and then a prototype for properties. This same kind of system works where you have a super calling up. So there are some gotchas if we wanted to pour Ember apps and syntax over to this, right? We have a whole new syntax which means we need to use a transpiler. We can't polyfill a new syntax. It's something that has to be parsed and has to be outputted as our ES5 code. There's changes in the way that super behaves. Both in the syntax of it and actually when you look at the spec in the way that semantics work, what properties it has access to. Mixins, there's no real story for mixins here, right? It didn't look like there was anything that we had as a solution for that problem. There's no set unknown property which is something that we have in Ember today and that would just end up disappearing. Merged and concatenated properties are something that we would, there's certainly no allowance for but we can probably implement on our own and we always need to consider the transpiler output. So what does Babel actually do and is that still performance? Is that still something that works like people expected to work? There are changes we need to make to make sure it doesn't, when Babel compiles code, it outputs code that is used locally in that scope. We need to make sure we don't ship that code like a thousand times for every file and Ember. So this gets us maybe halfway there to the syntax. Just let alone even all those problems, we're still not quite there yet, right? We didn't have a bunch of other things that we would expect like computed properties and observers. So there is a discussion about introducing decorators into ECMAScripts and this is something that Yehuda has been advocating for and Angular has also been advocating for something similar, other decorators or annotations. So I'm going to use an example here of decorators and this is taken from something that Yehuda was working on. Adder, online two and three is a decorator that implement as functions so you would have a function called Adder which would be passed the class itself and you'd be able to attach things to it. Online nine, we have a descriptor that's focused on that one property, online 10 and that would get passed like the class and that property name and the actual descriptor like the getter itself and that would allow you to modify it or wrap it in proxies and all kinds of stuff. So we'd be able to say depends on turn it into a computed property and give it dependencies. So how do we actually, given this like landscape of things that aren't compatible and some things that don't actually exist yet that are totally just taken literally out of tweets and notes from the ECMAScripts board, how do we actually go about trying to align with this? I think it's not going to be, it's not like a switch, I wish I could say that we're here and we have like a switch that we can flip to move over to them, but it's not gonna happen. In many ways, this is like what frameworks do, right? We're ahead of the standards and so we're identifying the problems and the challenges that need to be solved in the standards themselves. So our strategy is probably going to be something like a private use so we can, there's a lot of places in Ember today internally where we use bespoke ES5 classes. We use functions with things put on the prototype. We have our custom super syntax that we sometimes use or super pattern that we sometimes use inside of Ember. If we can replace those things with actual ECMAScripts six classes, I think that's a really good starting point. And then we can provide a legacy wrapper around that that gives you Ember objects so you can continue to use Ember objects and maybe use some new syntaxes as a carrot to get you to move over to the new thing instead of using the legacy wrapper. Some ideas for what this could look like. This was actually just modified with stuff just now outside. When you're extending a class in ECMAScript six, you can extend any object or any other class. So Ember object itself, of course, just returns a JavaScript object that has a lot of extra stuff on it. I'm missing a closed parentheses too. Yeah, yeah, painful. Yeah, glad I'm not here doing Torren's thing. So you've got your super call in there, but some things aren't ideal here, right? You're using this.super on line seven. So we haven't really moved you over to ECMAScript six classes. You're still using like Ember classes for most of your things. It's just so you get this nice sugar for class whatever extends something else. So pleasant but not ideal. However, it would maybe unblock us if we could get Ember object itself to be just an ECMAScript class. For some things, it would be appropriate where you don't need observers and you don't need computer properties. You'd be able to use like the full modern syntax, which would feel really good. And then we could implement things like merge properties and can cap properties inside of our Ember, custom Ember object here. And this would work pretty well for components. Largely because of the work that Tom Nihuda demoed with Glimmer. We require far fewer observers. So we don't really need computer properties and we don't really need observers in our components as much as we did before. And this might give us the opportunity to move them over to a more pure ECMAScript class format and maybe get some performance benefits out of avoiding observers at the same time. So I think there's a lot of promise for that being one of the initial spots where you could start using ES classes in your apps. This is gonna be a story of Ember 2.0 to 3.0. It's not a story of Ember 1.0 to 2.0. And I wanna remind you all that. Standards are a two-way street. When you run into problems with them, I guess I don't encourage you to immediately open up an issue on GitHub to push it up to them. But if you explore it and you think that you find something that can be done better or can be improved upon, really the Ember community is at the vanguard of working with standards groups. And I think that we have the opportunity and kind of clout to actually have some influence. So that's really exciting for us all as members of the community to know that we're really building the web and building the future of our own careers and everything else in technology. Great, so we have one more thing. Woo, woo. Okay. So a few weeks ago we announced that we were gonna do an unofficial Ember community survey. I'm not gonna share everything here. I'm gonna tell you guys that there's a link that you can go if you wanna see results from the survey. We put together a summary of what we think are some salient points. And you can of course download the full results if you wanna do some deeper analysis. I'd like to thank Brian Ronells who's on Twitter as ClimbingDark who's been our intern through this process and did a lot of emailing every single meetup organizer on meetup.com that he could find and reaching out to a lot of different people to get them to share the survey with you guys. We got over 900 responses, which was really exciting. Two, just two things that I wanna share from it. The first one is this is a list on the left of what people use number four. And there's a lot of people building product. And I think that's really exciting as someone who loves building products and thinks that that's like a really fun part of the web, an important part of what the web does. So that's really great. The second chart on the right is how many people plan to be hiring the same amount or more Ember developers next year. And it's about even in between the same amount or more. And I think that's a great sign for growth that companies are not ramping down on Ember. They are at least half, well short of half of them are ramping up on Ember. And that's like super exciting to see as someone involved in the community. And the second thing is that this is our chart of who has adopted releases. And when you look at this, it doesn't actually say here, yeah, 75%. So above the one nine, which was the stable when we started this and one 10 came out while we were doing it, one nine to the right was 75% of respondents. So 75% of people are using latest versions of Ember. And that's like a really exciting testament to our semantic versioning and the stability that we definitely all I think value at this point. And that's about it. So thank you, you wonderful Ember community people.