Give it up for Conster, everybody.

We're going to give you something to turn up for now. Turns down. 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,000, 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. Some 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.

Growth of the Chrome extension Ember Inspector has been absolutely huge. We've got 70,000 installed users now, which is a really big number. And the Ember Inspector 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, Teddy. Nice job, Teddy.

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 like 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 is, as developers, 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 had 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 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 201 Created does a community wide survey to help us better understand ourselves, to help us measure the Ember community.

A really big thanks to them, and in particular their intern Ryan Labov 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.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 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 December 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 Builds, which we'll talk about a little bit later, and one of them was making plugin APIs more public. So plugins use 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 in exchange for that, you're rewarded with some semper 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 sanctioned 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 scatter shot 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 a thousand 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 less time

that people use. 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's 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 going to 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 give handoff 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 subteams goes into a lot of detail. I think I was very influenced by it, and you should definitely check it out if you want to 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've 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 subprojects 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 subteam, Ember CLI, and I want to 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 Terzic, Christopher Person, Stanley Stewart, and Brendan McLaughlin, many of whom are in the audience today. So let's give them 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 Gengler, 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 could have 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 could have 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 Mendez, Leah Silber, and Todd Jordan are the four founding members of the learning core team, with Leah acting as the core team liaison. And Leah'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 flipped out, that might have been my fault. But we'd like to welcome Dan Gephart 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 going to be like you. It's like Pokemon. You've got to 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 going to 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 members to the core team today. Did you want to 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, all the projects I've been part of and Ember as well, the alumni process allows you to retain all the rights of a core team member with none of their responsibilities,

which is actually a pretty good deal. So we're very grateful for everyone's service. The first we're announcing, Trek Glockey 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, ah, I'm going to 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. 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, and it personally was very

influential to me, and it's probably the number one reason I say Trek's name out loud to other people. So definitely go watch that talk. It's great. And the second person we're announcing, joining the alumnis today is Alex Machner. He told us that he has far more important things to do with Ember concurrency than work on Ember. We'll 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. So thank you, Alex, for your service.

I'm actually pretty psyched that Alex has worked on Ember concurrency, and it's great you can continue to work on Ember stuff without working on the core team. Yeah, now that we have an add-on story, it turns out you don't have to be on the core team 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 The thing I always remember Peter for is when we first called Sprout 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 a few hours, renamed 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 Gaurav is actually one of my favorite things the community has built recently.

For the longest time, we were thinking, what are we going to do when we switch the ES6 modules? Obviously, JSPin and JSFiddle don't support it. Are we just going to have to tell people that they have to use globals in JSFiddle? And Ember Twiddle came to pass, and these days

Gaurav maintains it, and the fact that it exists is really the difference between saying, basically, there's nothing like JSFiddle for the modern Ember, and there is a very easy and very pleasant and nicely used thing for the modern Ember. Another example of this is Ember Concurrency. For months and months and months, Makdi 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, because it turns out nobody can do that. I'm trolling. A 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 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 use, it doesn't hook, 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 an enumeration, 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 and the core team necessarily have to maintain. It's something that the community does. It's great. Finally, there's a 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 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 Packer News comment that tells someone to calm down recently about this. It 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. 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. 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, Torin Billups 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 CLI, 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 Nilay 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 asked most developers to explain the difference or the use cases where you might want a 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, 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 in 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 responsible 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 us to.

And then it brings you to the App Store. I see. So we clicked on a link from Twitter. Brought us to the App Store. Seems good. Now 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 are, have clicked on the link from Twitter that they wanted to get the content, but it seems good. Now we go back here. Oh, well, we're not logged in, so we've got to 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 your cookies. So no problem. This is real, by the way. This is not staged. It 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 going to get back. Of course it's going to 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. The App Store is 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 percent 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 percent 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 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 going to forget you. And you can send push notifications, and I'm sure you've all used apps where they gently remind you to reengage and increase the stickiness and virality ratio, what is it called?

Virality. 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 going to 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 service worker.

iOS has had add to home screen since iOS 2. Push notifications are available with service worker on Android. App cache and service worker let you make your application available so it launches super quick. And service worker app cache and the combination of those with IndexedDB 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 app cache, it's very unlikely that they're going to spend a lot of time to fix app cache 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. 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 in tension 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 Jorrithegg'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. And that's 39 megabytes on top of Cocoa that is

baked in, 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 block 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 categorized 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 second boot, 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 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 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. And fast boot is a really good fit for that scenario. And we've talked about Project Svelte 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 removed 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 it's something that we bet on a long time ago, a couple years ago. And then engines, as 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, and 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 2010, and for some reason it's just lost to the sands of time.

And we actually used to do it in Sprout Core, and I think we're going to 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 want to 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 you two talk about AppCache first. Sure. So 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 going to get it. So if you want to bet hard on Service Worker, you're going to 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 leads to a question, which is, 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 does it. You can sort of think of it as XHR. 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 ink 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. 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 the 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 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 8 and IE 9.

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, it 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 it is a capability that the web has had since 2011. So I'll just give you an update on FASTA, which is the second thing I want to 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 they've got it running

in production. Sorry, I had to start it. So this is 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 fastboot 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 fastboot today so we can start ironing out the bugs. We're launching a new fastboot 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 fastboot are not useful. Server-side 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 want to give you just a really quick demo. This is what it looks like when I deploy the fastboot website. I'm just going to 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 npm install. So it's literally, you want to deploy an app to fastboot.

You don't need to do any configuration. You just add the fastboot add-on, push to Heroku, and you've got an app that's running. A really important thing about all of this is that fastboot, 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 dot set timeout 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 fastboot out of the box and can be deployed to Heroku this way. OK, 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 Gengler to add fastboot 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 fastboot. And we will be shipping fastboot 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 can exist in the world, and they can stagnate for years like XHR or like AppCache if they're not turnkey, 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, the time it takes to download the assets. So we talked about AppCache, we talked about fastboot. 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've talked about before and 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, Ember should be faster. Ember should be faster on its own, out of the box. I shouldn't have to worry about smoke and mirrors if 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 large arrays. So people who are new to the community in the past year might not remember, but there was an API called ReduceComputed that was a very, very painful API that was working around the fact that our underlying

engine wasn't very good at dealing with large 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. While we significantly improved the rendering performance of basic constructs like curlies, the if statement, the each statement, the work on Glimmer 1, 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 we regressed performance, and that worked somewhat. 2.4 is now noticeably faster than the original 1.13, but fundamentally, that wasn't gonna 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 codenamed 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, 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 DBmon benchmark from last year. We have 100 rows, and basically the way this works

is there's 100 rows, you scroll, I'll scroll just to make sure, nothing on my sleeve, there really are 100 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 DBmon 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, and 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 DBmon 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 1,000 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 tool tip. 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- So 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 bit 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. M. Moon 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 pre-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 re-render, if we reload now and click the play button,

it's 10 FPS, it 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 screen flow or something like that. But it's about 15 FPS reliably, which is not as good as we were at.

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, 1,000 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 CLI app running real Ember component. Uses the router, everything. The code that we ran on Ember 2.4 is the exact same code of Ember, Ember 2.6 Canary.

We're using the new lifecycle hooks here, but those lifecycle hooks existed in 1.13 and they're part of the API. So this exact same code runs on Ember 2.4, 2.6, 1.13, and Glimmer 2.0 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 of the 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 a ES6 class, and the template is actually almost identical. So this is just bare Glimmer if you were to use the Glimmer library bare. So let's look at that and start it. So again, same story. And 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 requestAnimationFrame,

so let's make sure we use requestAnimationFrame. 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 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 2 is even faster. So you might be asking, well, it's great that we're faster than we were before and faster than React, but how do we get to Glimmer 2? How do we get to the holy grail of being just as fast as I showed on Glimmer 2?

And interestingly, at this point, the only real difference between the Glimmer 2 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 2 into Ember, we think that we'll get much closer to the theoretical performance of Glimmer 2. So mostly object model improvements. So you might have noticed

that I have not talked about initial render. It's just we have 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 Glimmer 2 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 Glimmer's rendering performance is pretty close to React, and there's still some more we can do there. But again, 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 as you 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 headroom of things that we already know how to do, we 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 2 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 wanna talk about a lot of things that are on this screen here because you should come to my talk tomorrow with Godfrey. But the Glimmer 2 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 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's MacGyver, well-known for stopping nuclear explosions

with chewing gum and baling 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 gonna wait for some browser vendor 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 the web development community could cobble together amazing experiences with chewing gum and baling 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, we're gonna start down this path, we're gonna hit some problems that are gonna not be easy to solve. If the solution to a problem is not immediately apparent,

we shouldn't give up. If we could figure out how to build a vibrant web ecosystem on top of IE6 running on single core Pentium 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, IndexedDB, 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 just sucks and 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 the schedule app, so it will be an app that you can use to find out what's going on. Yeah, we have no internet. We 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. It uses LiquidFire for animations. It supports add to home screen.

And 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 us not working very hard to make something amazing. Let's all build amazing things on top of the web. Thank you.