 Give it up for Comster, everybody. We're going to give you something to turn up for now. Turns down for? I'll explain what turning down is to you later. Well, thank you guys so much for joining us this year for EmberConf. It's incredibly exciting to be here. This is such a huge crowd. Last year, we were on the stage, and we got up before you. And we announced Ember 2.0, which was really exciting. And two of the most exciting things about what we introduced, two big initiatives. One was Glimmer, a brand new rendering engine for Ember. And the other was Fastboot, which is the ability to render your Ember apps on the server so you can deliver content right away to your users. And we're going to give you an update on both of those things today. But first, I just want to talk a little bit about the momentum behind the community, because the last year in Ember has just been incredible. So last year, we had just over 600 attendees. And this year, we've got almost 1,950 people, which is awesome. And I can tell you from looking on the stage, it is now almost twice as intimidating as it was last year. It's like a sea of people out here. We'd also like to welcome our newest member to the community, Zoe, who you probably read about. So hopefully, you'll be seeing a lot more of Zoe around the internet. And you've gotten some swag related to Zoe. Zoe swag. So the other thing that's been huge in the last year, I think, is Ember CLI adoption. It's really strange to think about that even a year ago, the idea of Ember CLI being the bedrock of the community was still, I think, kind of a controversial idea. And Ember 1.0 didn't even come with Ember CLI. That's right. Yeah, there was no Ember CLI with Ember 1.0. But in that time, I went back when we were preparing for the presentation and just gathered some stats about Ember CLI. And I thought it was really incredible. Since last EmberConf, there have been 52 million live reload events in Ember CLI, which is a lot. That's 4.7 Ember Serves. So that means that you have a problem. 4.7 million Ember Serves. 4.7 million, which I think, so what we can gather from that is that people make about 10 changes to their app before they give up and they quit the server. OK. Growth of the Chrome extension Ember Inspector has been absolutely huge. We've got 70,000 installed users on Ember CLI now, which is a really big number. And the Ember Spectre actually has a huge amount of stars. It's always the five stars very well received, very popular add-on for its kind of thing. That's right. Nice job, Petty. Nice job, Petty. Yeah. And looking at the download statistics last year, sorry, last year, last month alone, Ember CLI was downloaded just over 300,000 times. So clearly, there's 1,000 people here, all of these downloads. People are actually using the tools. Ember, there's a tremendous amount of momentum behind it. And last year, we saw a few different companies. I think this is really exciting, picking up Ember, deploying it to the production. And the important thing here is that these companies that you see here, the products you see here, these aren't people who are just dipping their toes in Ember. These aren't people who are rewriting one page of their Rails app. These are people who are rewriting their entire product and betting big on Ember. And so to the people who work here at these companies and everyone who's working on products with Ember, we just want to say that we really appreciate your vote of confidence, and we're not going to let you down. But conversely, one other thing that I think is really exciting is this. It's not just big companies adopting Ember. It's smaller teams who use the productivity that Ember gives them to be able to punch above their own weight class. To me, that's the most exciting use of Ember as DHH said in Israel's talk, preppers. You're starting a new company. You have a new product. It's maybe you and one or two other people. Ember gives you the tools so that you can produce as much as a much larger team. So there's a lot of different kinds of teams using Ember. I actually personally work on Skylight, which is a very small team that ships a competing product to a massive company, a publicly traded company. But I also work directly with LinkedIn for the past year and they're themselves a publicly traded company. And there's a lot of different teams using Ember, and different Ember teams have different needs. And we knew that when we started, when we decided to go with the six-week release cycle in the first place, we knew that this was going to be something we had to think about. And so we started off with three release channels, the Canary Release Channel for people who are really willing to take on some risk in order to get some features early, the Beta Release Channel for people who are willing to take on some features once they've gone through their paces, and the Release Channel for people who want to wait for things to be solid and get some semper guarantees. And over the past, as we went through the 2.0 process, we were actually the first project that has a six-week release cycle that went through a 2.0 process, a breaking change process. We knew that we had to make some changes to the very simple three channel system to account for the larger number of people, larger kinds of people using Ember. And over the past year, most notably since Ember 2.0, we've added two pretty big pillars to the Release Channel strategy. We have the RFC process now where any member of the community can submit an RFC, and this is quite often something people do, and the Ember core team has to go through exactly the same process to get exactly the same kind of community support before we can start moving things through the process. And then finally, and I'll get into this a bit more, we also added an LTS channel for people for whom the six-week release cycle is too fast. Now, every year, 2.0.1 Created does a community-wide survey to help us better understand ourselves, to help us measure the Ember community. We're really big thanks to them, and in particular their intern, Ryan LeBeauve, for doing the heavy lifting on the survey. So this year, we had 1,800 survey participants. That's twice the amount of survey participants as we had last year. Both years, we did a pretty big heavy lift to try to get everybody we could think of to fill it out. And this is just an astounding number, almost 2,000 people filling out the survey. So we think we've learned a lot. One thing that's really great that we learned from the survey is that 76% of people who fill out the survey have an Ember 2.0.x app. And this is something that we hoped would be true. We hoped that after shipping 2.0, people would move to 2.0. But if we hadn't done our job, well, if we had completely failed, you could imagine a lot of people, a lot more people would be sticking around 1.x, clamoring for us to maintain a 1.13 community for a long time. But what we've seen is that when people get the chance, when they really want to, sorry, when they get the chance to upgrade, people really want to upgrade. That said, there are still 36% of people have an Ember 1.13 app. And we are very interested, we're still thinking a lot about what we can do to help these people, and I'm sure there's many people in this room who are still on 1.13, help them transition to 2.0. I think the big thing for me is that almost everyone who's on a 1.13 app, given the chance, would love to jump to 2.0, and we should make that as easy as possible when we've thought about it. So 1.13, like I said, was the first time that a six-week release cycle project ever had to go through a breaking change, because of course Chrome and Firefox, where we got the six-week release process from, is not allowed to break the web, so there's no breaking changes. So we sort of have to pave the way for what it means for a six-week release cycle to have a semver breaking release. And we learned a lot from that process. Obviously, as we were paving the way, we made many mistakes. And one of the things that we did right after Ember 2.0, a month or two after Ember 2.0, is I wrote this RFC called Refining the Release Process, and it talked about three things that we can do. One of them was LTS, one of them was SPELT build, which we'll talk about a little bit later, and one of them was making plugin APIs more public, so plug-ins to public APIs. You can definitely go check it out. We merged it a while ago. But I think part of the process of us using a six-week release cycle and having a lot of different kinds of community members with different needs is that we spend a lot of our energy constantly thinking about refining the process so that it works for as many people as we possibly can. It's very important to us. So if you haven't seen the LTS release, let me talk about it for a minute. The existing release channel, in the 1.x series, the existing release channels allow you to make a trade-off. On Canary, you get features as quickly as they land, but you get no guarantee about what those features mean. You can break them whenever they want. On the stable release channel, you have to wait about 12 weeks for features to stabilize and make their way through the beta process, but as an exchange for that, you're rewarded with some Semberg guarantees. And in principle, and this is what we thought in the 1.x series, this provides enough flexibility that you need to make the stability versus features trade-off. But it turns out there's another thing that people don't think so much about when they think about stability versus features, which is how often you can schedule an upgrade, and how often people can schedule an upgrade actually has a lot to do also with how fast the ecosystem is able to move along. So while Ember may be upgrading every six weeks, that doesn't mean all the add-ons in the ecosystem are upgrading exactly every six weeks in the same cadence. And so the idea behind LTS releases was to acknowledge that this is the thing that happens. Some people can't upgrade every six weeks for some reason and some add-ons take a little bit longer to upgrade and to give community members who want a longer cadence an alternative sanction schedule that works better for users who prefer a slower pace. And the idea is that by synchronizing the timing that these users upgrade, the community can decide to focus energy on specific versions rather than a scattershot attempt to support every possible combination of every version and every plugin. And this should, in general, result in more consistent support and easier upgrades for users on the LTS channel than people who just decided to pin to some random version of Ember 1.x. Now, as I said, the Ember community has a lot of different kinds of companies. One thing that I'm very proud of and very happy about is that the Ember community, and there's 1,000 people in this room, it's a big community, is not a community that is mostly funded and powered and operated out of one company. There's a large number of companies. These are four of the biggest sponsors, but there's a lot of companies that sponsor even a less time that these companies sponsor time for people to work on Ember. So there's not any one bottleneck where some company could die and shut down the entire project or some company could decide it has a different strategic goal and suddenly the whole project shifts into a different place. The fact that there's so many companies sponsoring real time means that the Ember is a real project that has real resources behind it, but it's not centralized in any way, and I think that's really great. Obviously, this requires a lot of work by a lot of people, and so today we would like to more formally recognize a lot of the people who have worked so hard to make it happen. Part of the way that we're gonna do that is everybody knows the core team. There's something like 15 people on the core team now, but as the Ember project has grown, it has gone beyond the scope of any one person to keep everything in their head, and while the core team is really great at managing big decisions, cross cutting concerns, keeping the experience stable and understandable, making sure that changes happen at a predictable pace, there are things that happen in the project that really make more sense to hand off to a team to do most of the day-to-day decisions, and the Rust project in the RFC that the Rust project wrote about sub-teams goes into a lot of detail. I think I was very influenced by it, and you should definitely check it out if you wanna learn more, but the basic idea here is just that we need some amount of centralization for visioneering, for leadership, for keeping everyone pointing in the same direction, but at the same time, we don't want too much centralization. We don't want everything to be bottlenecked on the core team, and so today what we're announcing is that we're sort of formalizing something that we'd already been doing inspired by the changes the Rust project made to say that their core team is responsible for overall direction and cross-cutting concerns, and then there are three other very large sub-projects that are very autonomous that do their own thing and are responsible for things that are not cross-cutting concerns. So Ember Data is a new sub-team, Ember CLI, and I wanna talk for just a second about learning, so we didn't call the learning team the docs team, and that's because docs are just one part of a bigger, more holistic picture of learning. People learn in a lot of ways. People learn from the first time they come to the website and all other kinds of ways, and so the idea is to make learning a central part of the whole process, and to that end, very recently, we added to the Ember RFC process a section, so the RFC has a bunch of questions you have to answer like, what is the design problem you're trying to solve, and there's a new section that was now added, which is how should we teach this? So the learning team is responsible for thinking about how we should teach new features both in the docs, the APIs, but also the website and other areas. So let's first talk about the Ember Data team. I'm excited to announce today that we're formalizing the Ember Data core team, Clemens Mueller, Igor Terzik, Christopher Person, Stanley Stewart, and Brendan McLaughlin, many of whom are in the audience today, so let's give him a big round of applause. So Igor has been on the core team for some time, so he will be basically the liaison between the Ember Data team and the core team. Next, we're excited to announce the Ember CLI core team, Katie Ganglers, Stefan Penner, Chad Hayatala, Jake Bixby, Nathan Hammond, Robert Jackson, and Kelly Selden, so a big round of applause for these. So this one's a little unusual in that we have two core team liaisons, which is Steph and Robert, so hopefully they will be a gentle monarchy. An oligarchy, if you will. And then last, as you had mentioned, the learning team, again, the scope of this is not just documentation, it's guides, it's the website, learning to love Ember, API docs, and in general, our online presence. As you had said, it's really important to get feedback from this team because we take the learning process so seriously that we want to incorporate what these people have to say about what it's like to be a new user of Ember, and we want to incorporate that back into changes we make in the programming model. So I'm excited to announce David Baker, Ricardo Mendes, Leia Silver, and Todd Jordan are the four founding members of the learning core team, with Leia acting as the core team liaison. And Leia's been doing a great job managing that process for a year now. So, give it up. We're also excited to announce that we're adding two new core team members formally, although I think maybe word slipped out, that might have been my fault. But we'd like to welcome Dan Getpart and Godfrey Chan to the Ember Core team. So Dan has been around for basically ever, he's one of the, I mean, not in terms of age, of course, but I mean, but Dan is one of the most brilliant smart guys that I know. He's been doing a lot of really interesting work in terms of data persistence with Orbit, and we're really excited to steal as many of those ideas as possible for Ember data. And he's been working on engines. And engines is the other big one, and engines play a very important part in Ember's future, and they couldn't be in better hands than Dan's. And Godfrey, as a Rails core member, so he's going for his EGOT, so he's gonna be like you, he's gonna, it's like Pokemon, you gotta collect as many core team memberships as you can. So Godfrey has been doing some really incredible work on Glimmer, the rendering engine, and we're gonna get some updates on that in a bit. So welcome to both of them for the team. Okay, we are, it was with heavy hearts, no, not with heavy hearts. We're announcing several alumni's members to the core team today. Did you wanna talk a little bit about what the alumnization process means? So the main, the TLDR of the alumni process is that people join the Ember core team or the Rails core team or the Rust core team for any number of reasons, and they may be very active for a long time, and then eventually while they may have a great love for the project, they may find that for some reason or other they no longer have as much time as they used to have. Generally speaking, in all the projects I've been part of in Ember as well, the alumni process allows you to retain all the rights of a core team member with none of the responsibilities, which is actually a pretty good deal. So we're very grateful for everyone's service. The first we're announcing, Trek Milwaukee is joining us. So I first, Google did a Google image search for Trek, and it came up with a very silly photo of him when he was like 22, getting an award. And so I was like, oh, I'm gonna use this. And Yehuda said, no, come on, this is like a, you know, have some gravitas. This is a serious moment. We have to honor all the incredible contributions that Trek has made to the project. So I said, okay, fair enough. And I messaged Trek. I said, do you have a picture I can use for this slide? And he sent me this. So I think this just captures Trek perfectly. Trek, I'm sure everyone has interacted with Trek in some form online, but Trek was instrumental in, well actually the way we met Trek was he trolled us incredibly hard on Twitter about how crappy the Ember documentation was. And we said, cool story, it's open source, like why don't you do something about it? And unlike everyone else on Twitter, he actually did. So a big thank you to Trek for managing our documentation story and our ease of use story for so many years. And I personally, the thing I most cite Trek for is the talk he gave at EmberConf the first year where he talked about UI patterns, not UI widget toolkits. And I would encourage everyone to go watch that talk. It's really great. Personally it was very influential to me and it's probably the number one reason I say Trek's name out loud for other people. So definitely go watch that talk, it's great. And the second person we're announcing joining the alumni's today is Alex Machnier. He told us that he has far more important things to do with Ember concurrency than work on Ember. Will not stop talking about Ember concurrency. Alex you probably know as the DJ of EmberConf. You probably know him as Mr. Router. And also the author of very disturbing Photoshop mashups. Okay. So thank you Alex for your service. I'm actually pretty psyched that Alex's work on Ember concurrency and it's great. You can continue to work on Ember stuff without him on the court scene. Yeah, now that we have an add on story, it turns out you don't have to be on the court scene to do anything in the framework, which is nice. And lastly, Peter, who I think many people already knew this because it's on the website, but we just wanted to thank Peter. Peter is an absolute machine. You can throw almost any task at him and he will somehow power through it. Peter was actually, I remember instrumental in somehow we had massive numbers of GitHub issues in the early days and he was the one who always triaged them and made sure they were positive. The thing I always remember Peter for is when we first called the spot for you, you may recall, and at some point we decided to rename to Ember. Someone had to go in and rename space all of the entire repository. And Peter, I think in like a few hours we named space all the entire repository. That's right, so thank you Peter. So what's really great about the Ember community, and this is something I notice every single year at EmberConf is that Ember community members are leaders in the front end revolution. So some of that comes from of course the Ember project itself, but as Tom said, the Ember add on system and its predecessors give people the ability to do a lot of really interesting things in Ember without having to go in and work with Ember directly. This is actually something I learned from the Rails project to make sure that Ember was a good set of primitives even though it might have a nice layer of defaults on top that the thing underneath it is a really great thing to build on top of. So Ember Twiddle by Guarov is actually one of my favorite things the community has built recently. For the longest time we were thinking what are we gonna do when we switch to ES6 modules? Obviously JS Bin and JS Fiddle don't support it. Are we just gonna have to tell people that they have to use globals in JS Fiddle? And Ember Twiddle came to pass and these days Guarov maintains it and the fact that it exists is really the difference between saying basically there's nothing like JS Fiddle for the modern Ember and there is a very easy and very pleasant and nice to use thing for the modern Ember. Another example of this is Ember concurrency for months and months and months, Mocti wouldn't stop talking to us about RX Observables which are cool and I said to him at some point as several of us did like the add-on system is great, why don't you go work on that and show me something that is so good that you can use it without understanding RX Observables that turns out nobody can do that. I'm trolling. Relatively small number of people are willing to take the time to really understand RX Observables so maybe you could build something that has the power of that system without forcing of a steep learning curve and Alex created Ember concurrency which is an add-on you can use in Ember today. You should definitely check out his video and his repo but it doesn't replace anything about Ember and it's one of the first times that I looked at something about concurrency and I said that API feels like it belongs in Ember, it's really great so good job, Alex. Another thing and this is similar to Peter being a machine. So Katie maintains this website called Ember Observer and Ember Observer is just a categorized enumeration of all the add-ons in the Ember add-on ecosystem together with a bunch of information about how well they score for various reasons. You should let her tell you all about it but Ember Observer is another one of these things that it could either exist or it doesn't exist and if it exists it makes everyone's lives a whole lot better and I'm really glad that we have it and it's not something that we in the core team necessarily have to maintain, it's something that the community does, it's great. Finally, there's this, there's the general thing that people do on the web called occlusion rendering, you might have heard the term occlusion rendering from the React community, there's been a bunch of attempts to do this in Ember including Ember Collection, Ember ListView library but the RunSpired, who I think is probably here, works on a thing called Smoke and Mirrors which I think is pretty cool and again, this is not something that is part of Ember, it's something that takes a lot of advantage of Glimmer and he actually wrote a really long Kakadu's comment that tells someone to calm down recently about this, takes advantage of a lot of the primitives that Glimmer gives you to make things awesome but gives you occlusion rendering, I think this probably is a video, no? It was playing while you were speaking. I see, so it effectively allows you to do something that's pretty important to do nicely without a lot of buy-in directly from the core team but with a pretty stable API and I think that's great. So fundamentally we have a lot of good community work and I would be remiss to not talk about another category of things, so recently, Toran Billips wrote this library called Ember Redux and actually I really love the fact that people in the Ember community are using Ember's primitives to explore ideas from other ecosystems, I think it's really great that I think people don't necessarily think of Ember as having a nice set of primitives but it's something we've really spent a lot of time thinking about since the beginning, basically lessons learned from Rails and I really like the fact that people can do things like Ember Redux and it makes sense to do in the Ember ecosystem. Also, the Angular project has recently adopted Ember CLI as their CLI tool and I think that's really great, I think it's great that everybody can cross-pollinate. There's actually a talk in a couple hours which is about cross-pollination, maybe we'll talk about this particular thing but I just like the fact that the web ecosystem is good at this, I think that's great. So today, to get into the meat of the matter, we wanted to share with you our thoughts about the future of the web and how Ember fits into that and I think that the web has clearly won on the desktop. Most of the concern that people have when they talk about the future of the web is focused on mobile devices. So this is a quote from Neelak Patel who's an editor on The Verge and he says, apps have become nearly irrelevant on desktops because the web experience is close to perfect. While apps are vitally important on phones because the web experience is dismal and I think that we can all agree that given a sufficiently good browser, people tend to prefer web apps over native apps. For most things, not everything, you might still want Photoshop but for most things, most things you do on your desktop computer are on the web and I think if you ask most developers to explain the difference or the use cases where you might want one mobile web app over a native app, they would usually tell you something like this, web apps, instant boot, you can click a link from Google, it loads right away, you can share it, you can bookmark it, it's great for content, great for content sites but native apps, yeah, you have to go through an install process but once you install the app, it's really reliable, you can tap it, it's always open even if you're on an airplane or under a tunnel, it works offline, you can access device features that you might have access to via web APIs. In general, apps are for rich experiences while web apps are really great for reaching the widest possible audience. And the thing here though is that people expect to be able to instantly visit web apps from Twitter or Google. If you click a link, you expect something to show up, the content that you're after, you expect to show up right away. And people expect native apps to have an install step but then after that, it's very fast and it's responsive and reliable. And in fact, people believe so much in the power of the native app that the very first thing that they do when you land on their mobile app, you tap a link, is that they try really, really, really hard for you to install their app. So let's take a look at what this awesome native experience is like. So you did not allow it to do that. And then it brings you to the App Store. So we clicked on a link from Twitter, brought us to the App Store, seems good. Now, and this is a very optimal setup where we have extremely good 3G or Wi-Fi and we can download a 40 megabyte app relatively quickly, not super quickly, but relatively quickly. At this point, people have clicked on the link from Twitter that they wanted to get the content, but seems good. Now we go back here. Oh, well, we're not logged in, so we gotta do that. So it seems good. We'll log into the app, click on the app, and now we log into Facebook. Usually that's not easy because it's a native app that doesn't have access to the cookies. This is real, by the way. This is not staged. You did was like, please make a video of you logging into Pinterest from Twitter. I was like, please make it as real as possible, optimal setup. Okay, so eventually we go in, okay, eventually we're gonna get back. Of course it's gonna want push notifications. And now we're back to the home screen and we don't even have the content that we were looking at in the first place, right? So there's something, there's always like this black hole where the intents go to die. There's something very puzzling about this, right? So we said before that people, when they click on, people think that when you click on Twitter, you should immediately go to content. But somehow people feel very invested in this interstitial experience. So after seeing that horrible experience, that video is just over a minute long. It's really not hard to understand why that when Google studied this, they found that nearly 70% of all visitors completely abandoned trying to view their content after being shown this interstitial. They didn't cancel the interstitial out, they literally were like, forget this, close, don't even bother continuing forward. And given that that's true, it's not surprising that Google said, if you add an interstitial to your app, we will stop giving you preference as a mobile app on Google.com. Now under normal circumstances, I think you can agree something that caused a 70% bounce rate would be just disqualified out of the box. So let's contrast the native experience with the web experience, which is you tap the link, you open it, yeah, it's a little janky, like the web fonts have to pop in or whatever. But I think in terms of time, as a user, I would much, much prefer this experience to what we saw with the App Store flow. So to me, this experience is so much better, it's really hard to understand why they're so embarrassed of this that they would rather send people to the App Store and do something that we know causes such a big bounce rate that Google won't even allow you to do it without penalizing you. So why does your manager love the idea of interstitials so much? It's because when you finally do get to the native app, it can do things like these. And I categorize these into two different categories. There's engagement, you're on the home screen, so the user's reminded of you every time they flip through their apps, I'm not gonna forget you. And you can send push notifications, and I'm sure you've all used apps where they gently remind you to re-engage and increase the stickiness and virality ratio what is it called? Virality. Virality coefficient. That's the one. So wanky. And then experience, right? I think the key thing about native apps is once you've installed it, it is reliably on your phone. You're never gonna get a, sorry you are not connected to the internet message, you know once it's on the phone, it's there. Certainly if you were looking at some content a minute ago, you can look at it later. And many of these apps also work offline, which is key. But it turns out that many of these features, actually today, we have ways of doing all of these things on the mobile web. And we've had ways of doing almost all of them for years. The web isn't an inert thing, it's what we make of it. So for the home screen, you can use ServiceWorker. iOS has had, add the home screen since iOS 2. Push notifications are available with ServiceWorker on Android. AppCache and ServiceWorker let you make your application available so it launches super quick. And ServiceWorker, AppCache and the combination of those with index DB lets you write an app that works offline. And the thing is that the more that we take advantage of these features, the easier it is for the operating system to build a great user experience around them. So this is an example from Android on Chrome where when you use a web app enough times, it says, hey, do you want to add this to your home screen? And now this web app gets to participate on your phone as a first class citizen. But I think the problem is that if we as a community of web developers don't take advantage of these features every single mobile web browser developer is also an OS SDK vendor and they have to decide what to work on. And if all of us tell them, sorry, I'm not interested in AppCache, it's very unlikely that they're gonna spend a lot of time to fix AppCache bugs or implement new features. So many of these features that you see on this list that enable native-like features have been around for a long time. And actually we could all be building much nicer web apps if we made better use of these features. But the thing is that making great experiences with low-level primitives is really hard. Taking advantage of these things requires very sophisticated libraries like the ones that come in native SDKs like Cocoa and the Android SDK. And those libraries require code and it's not an accident that that Pinterest app is 40 megabytes, right? The more importantly, they require communities to work on them so that developers don't need to learn the vagaries and the details of WebGL or IndexedDB. They need to use something that they can just get off the shelf that makes them productive right away. And that is really intention with this idea, this argument that you've heard before, that web apps must be tiny. Like there is some minuscule amount of bytes of JavaScript after which people feel that your framework is just totally disqualified. So this is an excerpt from Henrik Dortheg's blog post about the viability of JavaScript frameworks on mobile. But there's a vicious cycle here. Because we don't widely use these technologies for fear of becoming disqualified due to our size, as a result many mobile browser vendors don't invest in them which leads them to have problems that makes people not want to use them. So there's this catch 22. And the thing is that Pinterest app that they redirect you to is 39 megabytes. You'd be laughed out of the room if you wrote a web app with 39 megabytes of JavaScript. You couldn't even show your face at EmberConf. And yet that is what our native counterparts get to work with. While Ember is too big at a few hundred kilobytes. 39 megabytes on top of Cocoa that is very large and baked in. So it's just unavoidable that as the amount of functionality that you have increases, the size goes up. And so what do you do once you hit this magic number? Do you just call it a day and move on to the next app? Well, guess this one's done, it's 50K. So the question we have to ask ourselves as web developers is what do we need to do to deliver native caliber features? How do we best take advantage of these primitives that are already in the browser today without giving up that instant feeling? And that's really the tension that I think everyone feels about mobile, right? The instant is very important for the web. I think everyone in this room probably doesn't like interstitials, right? But we need to still, if we try to create libraries to get native caliber features, we end up being slow. So we are going to use all of the tools that we have in our arsenal to help bend the curve and deliver these instant apps that still feel really great. 400K, which is like probably the average size of most Ember apps, 500K today. I think 650K is the amount that was considered disqualified by that blog post for this course. So 400K is better than 39 megabytes. But how do we get smaller while still caring about people who are offline, caring about people who want push notifications, caring about people who want really sophisticated UIs? So we have six pillars to improve load time. And by landing each of these, we can have a much stronger narrative than you can't use frameworks on the mobile web. And I categorize these six pillars into two different categories. The first is the first boot if you are a brand new user to this web app. And the second, if you are a frequent user, this is actually second on, if you are a frequent user of this web application. So Fast Boot, of course, lets you render initial HTML on the server so you can deliver the content right away. And that really mitigates basically most JavaScript file sizes. So long as what the user wants to do is enough that first thing that they want to do and gives you enough time to load the JavaScript, it's really hard to notice. And most of the cases where people really care about very, very little, small load times are cases where there's no notion of installing an app. There's only a notion that I want to look at some content. Fast Boot is a really good fit for that scenario. And we've talked about projects felt before, which is an ongoing effort. It's required a lot of under the hood work, but it's close to bearing fruit. And the idea here is a couple things. One is we just remove framework size by removing deprecated features. So we will have a build for people that don't have deprecation warnings. They get a smaller build of Ember. You'd be able to opt in. I want a build that has no deprecations before 2.4. And the other thing is that we can ship Ember as ES6 modules. And that means a lot of people say you shouldn't use a framework because you might only use 50% of that framework, but you're paying the full cost. And what this will let us do is analyze your app, actually see what modules you're actually using from Ember, and trim away any of the modules that you're not using. And ES6 modules are really, really great at this and something that we bet on a long time ago, a couple years ago. And then Engines, we mentioned before, Dan is working on. This will let you split up your app into different little mini apps adopting the Unix philosophy. So you can have one app that does one thing and does it well. And then you can load just that part of the app. And as the user navigates around, it's kind of on demand loading the resources instead of making them download this one big payload. And the key story with Engines is that the Engines API needs to work basically with the existing Ember that you already know. It doesn't require you to do anything new, except be careful about what different Engines can see about each other. So there's a couple other ideas we have here. So string loading, I won't go into it in depth, but is a way of not having to pay a big evaluation cost. You can ship your source code as strings instead of JavaScript and then evaluate them lazily. Google did a bunch of research into this in like 2010. And for some reason it's just like lost to the sands of time. But we, and we actually used to do in Sproutcore and I think we're gonna bring this back. Next, taking advantage of Service Worker, making apps available offline, giving us very precise control over the network flow and what we can cache, including prefetching resources. But of course Service Worker is a new technology. It's not available on all devices. Right. It is available everywhere today. So I wanna drill in on two of these six pillars. And we'll talk a little bit about some of the tricks that we're working on to deliver these instant rich applications. So I'll let Yuhu to talk about AppCache first. Sure. So sorry, as I was, that was awkward. As I was saying, Service Worker is a great technology. It gives you a lot of control, but it's available on 50% of all devices and that number is skewed because a lot of those devices are desktop Chrome. Mobile Safari doesn't have it. There's no clear story of when they're gonna get it. So if you want to bet hard on Service Worker, you're gonna find yourself not supporting iOS very well. The good news is AppCache was launched in 2011. It's based on every browser. And so that should, that leads to a question, which is why is it, given that we have this technology that allows you to download a bunch of assets and be sure that you have them reliably, why is it that people have decided not to use it? Put another way, you have literally zero excuse if the second boot of your app isn't close to instant. And certainly there should be zero downloaded bytes on the second boot because we have a technology that is five years old that doesn't. You can sort of think of it as XHR, right? In 2005, you really should have had no excuse to not build Gmail, but basically people weren't doing it for some reason. But if you try to ask yourself why are people not using this technology? Well, it turns out that there's been a lot of negative inks spilled about it. And if you go to the MDM website, it tells you please do not use this technology. Of course, the technology they tell you to use instead does not exist on many apps, on many devices. And strangely, this is not how we used to operate as the web, right? The web used to say, we'll use the technology that exists on all the devices until we can get the new technology and we'll try to polyfill, we'll try to lowest common denominator. Somehow we lost the plot on this. But certainly if you go to this site and look at it, it will not be convinced that this is a good technology that you want to use if it literally says it is discouraged. There's also been a lot of, there's been a lot of blog posts. This is I think the most famous one because of its title, which is basically saying appcache is broken. I actually agree with this. Service worker came about partly because me and other people found problems with appcache that we couldn't fix without begging. Spec authors to fix the spec. We spent six months on very tiny fix and we eventually decided the better answer is give the developers the power. But that really is unrelated to the fact that appcache already exists in a lot of browsers right now. What browsers you ask? Well, basically all of them. It doesn't exist on IE 899 and the good news is that appcache as a feature degrades pretty well to browsers that don't have it but you can pretty much bet on its existence in a large number of browsers and you will then get reliable instant assets. So that's really great. And as we've been saying, the key to appcache, I think people got confused about what appcache was for because I think it was pitched as a grand unified solution to the offline problem which it was not. But what appcache does, one thing and does it well, it allows you to get a bunch of assets in your device that you can reliably access atomically regardless of the network quality. And that is a capability that did not exist prior to 2011 and is a capability that the web has had since 2011. So I'll just give you another, an update on fast, which is the second thing I wanna talk to you about today about fixing load time, making big apps instant. So let me just show you an example. This is from dockyard.com which is, they've got it running in production. Sorry, I had to start it. So this is dockyard production on the left. Sorry, no, that's slow boot on the left, fast boot on the right. So as this plays, this is on a simulated 3G network and what you'll see is that the content arrives for fast boot much, much faster. So dockyard is one of the first sites running in production. Along, also, Bustle, we're using it for doing pre-rendering to deliver results to the search crawler. So the thing that I would ask for you today is that if you have a need for SEO or if you have a need for doing any kind of rendering on the server, I would really like you all to start using fast boot today so we can start ironing out the bugs. We're launching a new fast boot website today. You can access it right now, www.ember-fastboot.com. It's got great documentation. We're working on a lot more. And one thing that we focused on is making it really easy to use because tools like fast boot are not useful. Server site rendering is not useful if you have to take your top engineer and send them off for a month to go figure out what the solution is. So I wanna give you just a really quick demo. This is what it looks like when I deploy the fast boot website. I'm just gonna push to Heroku. So Heroku, I've been working very closely with Terrence, with Terrence Lee and he's been doing some really awesome work to make the experience of deploying an app from Ember to Heroku really fast, really easy, really reliable. So this is sped up three times by the way due to MPM install. So it's literally you want to deploy an app to fast boot. You don't need to do any configuration. You just add the fast boot add on, push to Heroku and you've got an app that's running. So a really important thing about all of this is that fast boot for the most part doesn't require any changes to your application. It may require you to be a little bit more rigorous in places where you might have typed like window.settimeout somewhere in your app. But for the most part, if you use Ember APIs and use things like fitness or elements to do DOM punching, you get something that works reliably with fast boot out of the box and can be deployed to Heroku this way. Okay, so you should check it out. Check out the website. I hope you all use it. We're really excited. We're working with Katie Gangler to add fast boot as an input into the Ember Observer fitness function. So hopefully that will be landing somewhat soon in the next little while. So it'll be really easy to find add-ons for your app that are compatible with fast boot and we will be shipping fast boot 1.0 along with Ember 2.7. So please help us test it and use it now so we can iron out all the kinks so we have a really solid, really easy to use 1.0. Now something that we believe in very strongly is that web technologies can sit around, they could exist in the world and they can stagnate for years like XHR or like AppCache if they're not turnkey and if they're not super easy to use because in practice app developers don't have time to learn WebGL or Asmjs. Some very big companies may be able to allocate some resources to it but in practice unless we as a community all work together in much the way that we used to back in the jQuery days to take raw technologies, raw capabilities and turn them into very easy to use tools that people can use without understanding the underlying details until we do that these tools practically don't get used and I think that you can see that that's basically always true. So we've been talking about a bunch of tools that we have in our arsenal to try to attack the first boot problem and there's another part of the first boot problem so that's all downloading time and the time takes to download the assets so we talked about AppCache, we talked about fast boot but there's another problem which is how long it takes to render the app in the first place and there are really two approaches to this one that I talked about before I won't get much into which is rendering smarter like the smoke and mirrors approach don't render things that aren't on screen and there's a lot of really good research into that smoke and mirrors is used in production, it's great but another thing and people often say well smoke and mirrors is cool but really embers should be faster embers should be faster on its own out of the box I shouldn't have to worry about smoke and mirrors of all I'm doing is rendering 100 tags or something like that and so last year going into EmberConf last year we had worked on Glimmer, we announced Glimmer and what Glimmer did was it vastly improved re-rendering performance particularly when dealing with larger arrays so people who are new to the community in the past year might not remember there was an API called Reduce Computed that was a very very painful API that was working around the fact that our underlying engine wasn't very good at dealing with larger arrays and really what Glimmer was about was making that story a lot better and we did I think a good job at solving that particular problem but while we significantly improved the rendering performance of basic constructs like Curly's, the if statement, each statement the work on Glimmer one sadly and many of you probably know this regressed the performance of rendering new components and this hit component heavy apps really hard and that's sad because we really want you to be able to write apps that use components in a very lightweight way the way you would write functions and that's always been a goal of ours and so regressing performance was sad and embarrassing and so we needed to think about what we would do next and so the first thing we did was we did a lot of work to get Glimmer more back towards where we were before regressed performance and that worked somewhat, 2.4 is now noticeably faster than the original 1.13 but fundamentally that wasn't going to get us where we needed to be we needed to do a more fundamental rethink of what it is that we were doing and so around September last year so remember Ember 2.0 shipped in August around September I took a trip to Intercom and I started working on a new rendering engine code name Glimmer 2.0 and the idea was okay so we shipped Glimmer 1.0 we now know what the requirements are we built handlebars, we built HTML bars we shipped Glimmer 1.0 let's build something that's more directly tuned for the requirements that we now have gathered and so in September my experiments were very promising and when I got back to Portland I started working on Glimmer 2.0 with Godfrey now unlike HTML bars which was a thin layer on top of handlebars and left a lot of decisions up to Ember we baked a lot of core features right into Glimmer 2.0 most notably components so the fact that HTML bars didn't have components and Ember built it on top meant that there was this opaqueness between the two systems that made it very hard to optimize components in even some of the most obvious ways in terms of functionality the Glimmer that we have today the tilde IO slash Glimmer repository is a lot more like react than it was like HTML bars and giving the engine itself direct responsibility for these features has opened up a whole universe of optimizations that were not possible before now you might remember the famous or infamous BPMI benchmark from last year we have a hundred rows and what basically the way this works is there's a hundred rows you scroll I'll scroll just to make sure nothing on my sleeve there really are a hundred rows here and this is effectively the benchmark we showed last year we souped it up so that there's a play button there and an FPS counter but you can see it's pretty fast like you saw last year this is Ember 2.4 and it's actually a little faster than 1.13 and it's like 12 FPS this is DB Mon running against Ember it's actually running against Ember 2.6 canary with the HTML bars flag on but it's roughly equivalent to 2.4 and it's pretty fast we've actually racked up some wins since 1.13 here is the exact same demo running against Ember 2.6 canary with the Glimmer 2 feature flag on so let's look at that now again it's the same demo look you see there's all the same number of rows the code is exactly identical and if you hit the play button you'll see that it's about twice as fast so that's great but something that we discovered like I said when we regressed component performance is that while DB Mon makes a pretty good stress test of certain kinds of re-rendering it really doesn't capture enough of the way that Ember users build applications in particular there just aren't enough components this thing is 100 components every row is a component and so we wanted to make a new benchmark that more directly stressed component creation now a few months ago when we were working on Glimmer 2 we added this benchmark there's over a thousand components on the screen here actually each box is its own component and we kept the requirement to have stable DOM like in the previous one I think that was a pretty important requirement that React taught us all so we kept the hover tooltip and we know React is pretty great at this kind of thing it's kind of the gold standard for performance of this kind of thing so what you're seeing this is the React one yeah so what you're seeing here is the React version of this benchmark it's the baseline that we built to try to track how we would do it's pretty fast running at about 20 FPS trends a little down over time I think as V8 de-optimizes or something like that just so you know it's React 0.14 in production mode we made sure we're running it in production mode MMoon gave us some tips on how to really make sure we did the right incantations to make it fast sure there's some mistakes somewhere but we tried really hard to make it fast because really the point of this benchmark was for us to understand the baseline for ourselves now unsurprisingly if you run the same benchmark on Ember 2.4 you'll get okay re-rendering performance and if you look you'll see it's the same benchmark again every single one of these boxes is an Ember component this is an Ember.component and you saw it was a little pokey to render in the first place and if we reload now and click the play button it's 10 FPS at trends up there's actually some weird artifact here that I think has to do with screen recording when we ran this under scientific conditions we got about 15 reliably that 21 is something weird with screenflow or something like that but it's about 15 FPS reliably which is not as good as React good but not great so let's look at the exact same benchmark now running on Ember Canary today with the glimmer feature flag on it so let's take a look again it's the same code 1000 components you can see nothing up my sleeve so we'll reload the page and if we hit the play button what we'll find is it's fast and just to look at the code this is a real Ember CLIF running real Ember.component uses the router everything it's the exact same the code that we ran on Ember 2.4 is the exact same code of Ember 2.6 Canary we're using the new the new lifecycle hooks here but those lifecycle hooks existed in 1.13 and they've been part of the API so this exact same code runs on Ember 2.4, 2.6, 1.13 and glimmer 2 is faster now really interestingly our plan of baking components into the engine seems to be working this benchmark uses way more components than DBMON but it actually performs better and the reason for that is that we spent a lot of time really optimizing the use case of components because that's as we said a very important case and there's still a lot more that we can do sorry those were supposed to be screenshots but somehow they are not but that's not all so as I said before glimmer is almost the whole Ember Ember adds a few things about the object model and some compatibility functionality but the glimmer engine is actually capable of running almost the identical code that Ember runs so you can see here instead of an Ember component we're using an ES6 class and the template is actually almost identical so this is just bare glimmer if you refuse the glimmer library there so let's look at that start it so again same story I think it really is important to understand that glimmer today does almost all the things that you could imagine that Ember did before and actually we have to when we first did this it said like 72 FPS and I told Godfrey no, no, no the browser does not allow you to go faster than 60 FPS when you use request animation frame so let's make sure we use request animation frame but what that means is that our 60 FPS is not using 100% CPU which is pretty awesome so this is something that the glimmer library can do right now and it's something that we're interested in so to see, to look at this visually so react is faster than today's Ember at updating and you can see that we're much faster just Ember plus glimmer is much faster on Canary with the feature flag but glimmer too is even faster so you might be asking well that's, it's great that we're faster than we were before and faster than react but how do we, how do we get to glimmer too? How do we get to the holy grail of being just as fast as I showed on glimmer two and interestingly at this point the only real difference between the glimmer two story and the ember story is the object model and also interestingly a lot of the improvements that we made to the glimmer rendering engine are very applicable to the ember object model so what we're gonna do next is we're gonna take those same optimizations that we just did on the glimmer rendering engine and we're gonna apply them to the ember object model and we think that by doing that and we can do that as we continue to finish implementing finish integrating glimmer two into ember we think that we'll get much closer to the theoretical performance of glimmer two. So mostly object model improvements so you might have noticed that I have not talked about initial render it's just we have some something to say but it's just harder to make an exciting demo out of a thing that happens once so first of all in component heavy scenarios canary plus number two is 1.5 to 2x faster than 2.4 right now and again this is on the component stress test so we have a couple of scenarios that we look at one of them is this uptime boxes another one is a benchmark LinkedIn contributed that's very very similar to a scenario that they find to be performance critical and across the board we see something between 1.5 and 2x right now if you look at that in graphical terms you will see oh not as good story what you'll see is that bare glimmers rendering performance is pretty close to react and there's still some more we can do there but again you and you can also see that canary is much much better than ember was before right we're getting there but same question how do we get there and interestingly the answer is very similar it's very much the same which is that a lot of the improvements that we made to the glimmer rendering engine had to do with and I won't spill the beans you should come to my talk and Godfrey's talk tomorrow but a lot of it had to do with making the observer system more of a pull based system instead of a push based system and those same strategies those same optimizations apply just as well to the object model so we think we'll be able to improve the initial render performance to get more close to the glimmer theoretical and there's even more that we can do on glimmer I think glimmer initial render is actually not very close to theoretical maximum I think we probably have like two or three x head room of things that we already know how to do you just have to do them so now this is also just talking about wins in the render step there are other wins as well for example glimmer two templates are five times smaller than html bars and they are also lazily parsed rather than eagerly evaluated so that means that the payload of your ember application becomes both dramatically smaller and evaluates a lot less code when you boot and that is a very very big win for initial render performance and something that we will continue to look at finally don't want to talk about a lot of things that are on the screen here because you should come to my talk tomorrow with Godfrey but the glimmer two engine is really cool there are really great primitives that people will be able to use to take advantage of and come to our talk tomorrow learn how we have built a custom VM to build run FRP programs compiled from your templates if that sounds cool come to our talk and you will learn more now just to circle back around so we just talked there was an open question how many people will understand what this image is so this guy is MacGyver well known for stopping nuclear explosions with chewing gum and bailing wire and what we've been talking about the whole day today is how do we get not just very good apps that feel good that feel like native but how do we make those apps also be instant boot so the answer is not that we're going to wait for some browser render to come down from on high with a stone tablet and gift us the perfect API that will solve our problem the genius of the web has always been that web development the web development community could cobble together amazing experiences with chewing gum and bailing wire and then take those amazing experiences and make them accessible to millions of developers without having to understand how the underlying thing works and what I would say is let's start pushing the envelope again let's figure out how to build apps that load quickly the first time and feel great to use the second or third time and like we did on the desktop let's package up those solutions so they can be used by everyone if the solution to the problem some problem I'm we're going to start down this path we're going to hit some problems that are going to not be easy to solve if the solution to a problem is immediately not immediately apparent we shouldn't give up if we could figure out how to build a vibrant web ecosystem on top of IE 6 running on single core pantheon 3s we can surely build something amazing on the mobile web we have today and we can make it accessible to developers everywhere so we'll make this quick the way that we build web applications is fundamentally changing service worker is a big step forward web GL, index DB these are all really transformative technologies and they're all hitting all at once the way that we build these web applications is changing and we need to learn to believe in the power of the web get over this learned helplessness that we have that the mobile web is just sucks and let's just go make native let's just go write native apps let's work together to build up instead of building out as they say the web is what we make of it that's right so we think of Ember not as a JavaScript framework we think of it and our community as an SDK for the web we have to stop hand rolling to get competitive as a community we are going to do it we are going to build an SDK for the web and we need to work together to get it right thank you thank you very much in case what you're thinking right now okay in case what you're thinking right now is cool story bro you just said a lot of words but you didn't do anything interesting I don't know if the internet will be good enough here but you should go to bit.ly slash EmberConf app it's a the schedule app so will be an app that you can use to find out what's going on yeah we have no internet cannot do anything but it's a schedule app you should download it because it will allow you to find the schedule on your phone it uses AppCache uses liquid fire for animations supports at the home screen and it's not you know it's an app we threw together over the past week but it should show you that maybe the idea that you have about what the mobile web is capable of is really just about is really just about us not working very hard to make something amazing let's all build amazing things on top of the web thank you