 my first Ember camp in London and it's really amazing to be here with you all today. It is our honor to be the first to welcome you to Ember Camp London. I usually say it on my keynotes which are closing keynotes, so it's actually just true this time, not really a joke. All right, so let's dive into it. Usually at the beginning of these keynotes we like to give a little bit of update about the community. And we've heard you loud and clear. Ember's stability without stagnation, our policy of stability without stagnation is just not very exciting. Our RFC process gives you almost too much insight into the changes coming and that's why today I'm excited to announce the newest member of our core team. You may be familiar with him. His name is Boris. So we think that the trend on the web is clearly, on mobile devices, is clearly towards more web apps with technologies like service worker and push notifications. The mobile web is becoming a first-class app platform in its own right. And I think as we saw happen on the desktop web, once you reach a certain critical mass of functionality, users just tend to prefer the shareable installation-free web apps. They just end up being a better user experience. And we think of Ember as being the SDK for the web. It's all the tools that you need to build these great web experiences. Ember doesn't want to be the platform and we don't need to port a native platform to the web. What the web is missing and what native platforms have is an SDK that helps you manage complexity as your application grows and helps you package and distribute your app optimally to your users. What we want to do here is we want to build a solution that doubles down on the strengths of the web. We want to focus from the bottom up on building a world-class web application. And we like to say that web applications are not just good enough, they actually have real advantages that are good for real users. We say that Ember is a framework for building ambitious web applications, but what I want to do today for a bit is talk about what ambitious web application means in the context of a mobile web application. So on desktop, when we say ambitious, usually what we mean is a long-lived workspace application. And what that means is that people are willing to wait for a few minutes or a few seconds for the application to load, a few minutes would be ridiculous. A few seconds for the application to load because using the app is their primary activity at the moment. So something like Gmail or the Heroku dashboard, people are willing to accept a little load time if it gets them a snappy, productive UI afterwards. But the idea of a long-lived application basically doesn't exist on mobile. Mobile is for quick interactions. Very few people are sitting down for an hour to work on their Android phone, even on native apps. And that fact alone should really give the web an advantage because the web already places a premium on instant interactions. You get what you're trying to accomplish without an install step. Now, that said, an optimal mobile web application has basically three phases. First, we deliver raw content, just the HTML, just the content that you're after, ensuring that those on slow connections or people whose JavaScript didn't happen to load yet, get what they're after as soon as possible. The next thing that we do is we load the minimum set of JavaScript needed to add interactivity for that page, keeping transfer time and parsing time low. And once the user has an interactive page that they're interacting with, we can start preemptively loading other parts of the application, including frequently accessed data. Therefore, after that, subsequent visits and interactions are nearly instantaneous because they don't rely on the network. That is sort of the optimal story. That's the story that people want to do, accomplish when they're trying to build mobile applications. Unfortunately, building an application that takes this optimal approach has historically been very difficult, and mostly you hear about this from people who are building demoware on the internet. You mostly don't see a lot of real applications being built this way. And the reason for that is that there are sort of two camps that try to tell you what is the correct way to build an application. The first one is the progressive enhancement camp. Progressive enhancement, if you do it correctly, gets you the first two phases. You get the content part, just as HTML, and then you get the interactivity afterwards layered on top. But this approach inherently relies on server-side rendering, meaning that any kind of network flakiness makes interacting with the app feel slow, if it works at all. You also have to manually separate the behavior and presentation, rendering HTML, and then manually wiring up JavaScript after the fact. And because of this complexity, a lot of developers prefer the experience of using frameworks like Angular or React to write progressively enhanced applications. It's just too many details to get right by hand. On the flip side of that, we have the need to have resilience to have all of your JavaScript loaded for subsequent interactions. And on the desktop, that means that you have your workspace app up and running. You have downloaded all the JavaScript and now a user can interact with it. On mobile, this doesn't mean that you're living inside the app, that you have your workspace app up and running. What it means is making subsequent interactions that you get too cold as fast as possible by running them right on the device rather than having to communicate over the often unavailable or slow network. Now, phase one and phase two and phase three all have real benefits, but getting all of these things right at the same time is very tricky and basically nobody has the experience time or resources to pull it off. And this effectively has caused the world, like I said, to become polarized into two camps. The lightweight JavaScript people who say that instant load times are paramount and they ignore the bad network scenario. And people who favor developing native applications which are willing to take a hit on initial load time and with multi megabyte app downloads, sometimes as much as 100 megabytes of app download. But once you get the application on your mobile device, you get the resilience that you expect from the phase three over here. So unfortunately what you often end up with is a very compromised user experience. So here's a concrete example I can show you from just two days ago. I sent Yehuda a link to my Foursquare app. I was trying to tell him to come meet me for coffee. And so what happens is when you tap this link, you get the Foursquare mobile app, but it actually pops up this interstitial telling you to download the app and then you try to download it and you get an error. And now we're sent to the app store. And in the meantime, all I want to do is get the address so I can put into Google Maps and meet Tom. Yeah, he just is like, let me come meet you. And he's on relatively slow internet because he's traveling. And so we open up the app store. We start downloading it. You can see this takes quite a while. This application is actually like 29 megabytes and people say ember is big. And then once we're finished installing it, which takes quite a while, now I'm going to go back to my Hangouts app, tap the link again. And the irony here, okay, so I'll open the app, verify it works. But of course, it has lost that intent, right? It lost the intent that I was trying to view this particular business. So I go back and I say, let me try tapping that link again now that I have done as they asked me to do and installed the app. And the irony here is that actually it just delivers a very, very nice mobile web app. And so now I tap it, it integrates with my system, it opens up Google Maps app for me, and it's very nice. And this is the experience I should have had. That's what I wanted in the first place. Right. This whole flow wastes valuable user time. And for what? Someone believed that the fact that native app was a superior experience, and in particular, it has these re-engagement properties like push notifications, the fact that it's on the user's home screen. They thought that that made, that was justification enough for interfering with the instant load that we're used to getting on the web. But the question is, what if we could somehow design a programming model that didn't force us to make this trade off? So the benefit of an SDK for the web is that it knows how your app works top to bottom. So you can write your app once in this very declarative, modular way, and Ember can create different versions of your app from the same code. Now probably many of you who have used Ember are already familiar with this idea. When you're running in development, we create a version of your application that has assertions enabled, that has better error messages, and in general it's designed to help you as a developer fix bugs, but you don't need all that stuff when your users are running it because it makes the application slower. So we also do a production build that minifies everything together. It lets you fingerprint assets to put on a CDN. It concatenates the GZips. All of these best practices that you don't have to think about to ensure that when it's actually consumed by your users, they get the best possible experience. And most recently we added this idea of fastboot. So you install the fastboot add-on to your Ember app and now when you do a build it's actually producing two versions. One version designed to be sent to the browser and another version that's designed to be sent to this fastboot app server running in Node.js. And that's without making any changes to your code at all. Right, so single code base, no changes. We now derive three different versions of your application. And again, just a single add-on lets us do that. But this is just the start of the possibilities for what we can do in terms of creating these optimized experiences. So one thing that we're working on now is more sophisticated slicing and dicing. For example, we can examine precisely what features you use and automatically trim code for the features you don't use. We can also figure out what code is needed for just that particular route that the user is visiting right now. We can render it on the server and then we can stream the rest of the application out to the user only once they have a fully interactive page. You could also, for example, automatically determine what CSS is needed by the components on that page and generate just the critical CSS for the user when they land automatically. And later today Martin will be giving a talk on Service Worker, which you should definitely check out, to get a taste of the experimentation going on in the community right now to deliver these instant experiences where the tools understand the entire app and they automatically give you these performance benefits without you having to understand fully how they work. And Eric is giving a talk on CSS experimentation that should allow us to do more slicing and dicing in CSS as well. There's an analogy that I like to use here, which is if you ever built native applications like for iOS or, you know, with C++ or something like that, there's a different set of settings that you can use, say minus o3, you can say minus os to get optimized sizing, right? So there's these different settings that you can use to tell the compiler to give you an optimized build for specific environments. But usually when you build the whole stack yourself, if you build it from the ground up, you're not actually thinking about all the different ways that you might want to slice and dice your app. So maybe if you're lucky you have development and production if you took the time to build that, but the idea that one single code base can give you many different outputs really is dependent on having a single programming model or a single language that knows how to build these slice and dice targets. So basically what I think of here is that Ember is GCC minus o3 for the web. It allows you to say I've written a single code base and then I will give you an optimized build for the specific environment that you are talking about. By giving developers a single modular programming model, and the modularity is important here, it's important that you're not just writing one big giant file with a bunch of global variables, you get all of these three modes, the content, the initial interaction, and the resilience of getting your whole JavaScript application from one code base without having to think about which environment you're in. Because we have a conventional structure for how applications boot all the way to the lifecycle of when they're torn down, we can break your app up into pieces and serve it to the browser just in time, and that means you don't have to manually split your code up or write any of this infrastructure yourself. It also means we can run in other environments like Node.js pretty easily. So I want to ask you all a question, which is what is Ember for? What kind of things do you build using Ember? And what kind of things would you not use Ember for? So let's talk about the desktop. When it comes to building desktop web apps, what's Ember for? There's an age-old argument about the difference between web pages and web apps, but I think in reality we mostly agree there's kind of a continuum between those two. But all the way on the left, let's say we probably have something like a landing page. Now a landing page doesn't have multiple pages, so you don't need a router, say single page, single page app. You probably don't need services, and Ember data is probably not going to get you very much. And I think most people would rightly say that Ember would be overkill for a simple landing page. On the other hand, there are things that are unquestionably apps, and here people actually tend to use Ember a lot. They know that they're building a sophisticated app, and they know ahead of time that they're going to need all the things that Ember provides for them. So there's many examples. Here's just three, the Heroku dashboard, the squared dashboard, and the Travis CI interface. And these are all what we call workspace apps. So the definition of a workspace app is one that has basically the following characteristics. It's typically behind some story of authentication, although not always. Oftentimes, if these words be indexed by Google, that would be not a feature but a bug, because it violates your privacy, because now Google is indexing all your email. It's usually used for at least a few minutes at a time, sometimes hours. And so load time can be a little bit longer because that value is amortized over, let's say, half an hour. Also, visitors tend to be repeat visitors. You can count on many of your users at least having many of your JS assets warm in their cache. And because they have so much functionality, they tend to be worked on by larger teams. And actually, Ember wins a lot here. But unless you know that you are building something like this, people tend to view Ember as overkill. So these are some tweets that I found kind of illustrating this sentiment. And I think these people's analysis of the situation is not wrong. I think this is a correct analysis. Someone's saying, so Ember and Angular are clearly overkill for my requirements right now. I need something in the middle. Or I prefer React and Flux. In my humble opinion, Ember is cool in a complete framework, but also too bloated for the same reason. And on mobile, this phenomenon is exacerbated because of significantly tighter hardware constraints. And more importantly, because there is really no such thing as a workspace app on mobile. So the opportunities that people to get to use Ember are significantly reduced. And often Ember gets disqualified for pages simply because of its payload size. And even for apps on the mobile, because of the importance of load time in the mobile context, large file sizes can completely disqualify you. So one thing Malta Ubel said who is the project lead on the AMP project, he has identified that on many phones, on average, on a phone one kilobyte of JavaScript is equal to about one millisecond of UI thread stall. So for example, if you have a 200 kilobyte payload, that means on average, you're going to see about 200 milliseconds of delay, which isn't so bad, but now you have a megabyte of JavaScript and that's like a second of delay. So that's bad. So what can we do to mitigate this? And how can we make Ember apps load instantly on mobile devices? I'll let you talk a little bit about some of the ongoing work that they've done to deliver improvements on mobile performance today. So for the past probably, I've been working on an app for the past couple of years, which I'll talk about in a second, but for the past probably 18 months, a lot of what we've been doing has been laying infrastructure groundwork for things that we can do next. So for example, Glimmer One itself was mostly laying infrastructure groundwork that we can use to make Glimmer Two a thing that actually improves performance. Engines, which are a great feature for teams that teams can use today to be clear about the boundaries across their teams for a single application, we're going to see is going to lay the groundwork for lazy loading engines, which I'll talk about as well. Props to Dan Gebhart for doing a lot of this work. ES6 modules, which is a thing that we adopted a couple years ago, is actually pretty important for making, for having tools that understand what the dependencies across all these files are. And we standardize the syntax or ES6 modules a couple of years ago, sort of in anticipation of eventually being able to do more dead code elimination. And finally, Fastboot, which today is mostly useful for like SEO or static pages. It has been, is a good laying the groundwork for doing even more stuff on the server, stuff similar to what Tom talked about before. So like I said, I've been working with a team at LinkedIn for the past couple of years to build their mobile application. So about a year ago, a year and a half ago, so about two years ago they made the decision, they started maybe like 18 months ago. LinkedIn decided to build a mobile application in Ember. At the time I said, what are you doing? You should build your desktop app in Ember, mobile applications in Ember don't really mesh that well. But basically what happened was that they had an existing backbone application and the backbone application worked well for the small team that was working on it, but they very quickly reached the limit of how many, how many features and engineers they could put on this application and also maintain good performance. Sorry. No, sorry. So they had, they were basically had these very tight performance requirements that came from their existing mobile application and they also had a bunch of, they wanted to put a lot more engineers on this project and there were no frameworks that they saw at the time that were both fast on mobile and also designed to scale to big teams. So the decision that they made was that the best bet was to start with Ember and try to make Ember competitive from a performance perspective rather than to take another framework and try to make it more like Ember. So the thing about, the thing about LinkedIn is that they actually test on a wide range of real-world devices with their real application. So for example, they test on the Samsung Galaxy S3 which was a phone that was released in 2012. They always tell me, quote, you can still buy it at Walmart which is like Tesco or Carphone Warehouse or whatever. The point is you can still buy this phone in a store for whatever reason and so LinkedIn actually tests frequently on this device and I have to look at every single day how Ember is performing against a phone that was shipped four years ago. So we have a real understanding of how Ember performs on quote, unquote real hardware as people say. As part of getting the app into production, like I said, a couple of years ago Ember was not a good fit for mobile applications. The LinkedIn team has made a bunch of changes to the way that they package and deliver their Ember application. So for example, they have moved a lot of their modules to strings so that you can evaluate them lazily on demand. They also have moved to eagerly loading common modules to try to get all that stuff to happen all ahead of time instead of interspersed with the execution of their code. A bunch of other changes to sort of just how the application itself gets packaged. So this has nothing to do with changing anything about their code. It just reorganizes how the Ember payload is packaged and that actually produced a net 25% real-world improvement not in the rendering time but the end-to-end performance. So on a very slow phone, maybe it might take like let's say 10 seconds to load an Ember app, a very old phone and that's like a two and a half second improvement just by reorganizing the packaging. And so the cool thing about how LinkedIn works is that they don't want to be maintaining their own custom fork of Ember forever. They're in the process of extracting string modules, eager loaded modules and reorganizing their code into engines and lazy loaded engines. They're in the process of extracting all that stuff so that all of you can take advantage of that without having to be a company the size of LinkedIn. And I think that's really the promise of Ember's how Ember works which is that there's not one company that runs it, there's a lot of companies that are all taking advantage of each other's work and everybody feels the ethos of trying to extract things out into the world. So like I said, optimizations of 25% end to end for mobile simply by reorganizing the payload. And like I said before, a lot of the things that we did over the past 18 months have actually been foreshadowing things that we can do that will make very significant improvements. So Glimmer 1 maybe didn't give you an amazing performance boost but it laid the groundwork for Glimmer 2 which I'll talk about in a second. Engines on their own are more of an organizational principle but the engines programming model was designed with the idea that we can make lazy loaded engines which is coming pretty soon and which LinkedIn is already experimenting with. JavaScript modules on their own are just a nice programming model. They actually improve the programming of a JavaScript program but they also allow us to do more tree shaking more what we sometimes call spelt builds. And finally, fast food while maybe you think of it as something that is mostly about delivering HTML to your users, making the Visit API which allows you to under the hood visit a page in Node allowed them to not render HTML to their server but just figure out what HTTP requests will be made and just prefab the HTTP request and not do anything special with server side rendering. So these are all things that maybe in your app today don't have any obvious performance improvement but LinkedIn has used all these underlying things that we worked on for the past couple of years to already start getting some very significant performance improvements in their application. For me since we shipped Glimmer 1 last August or July I've been spending most of my time working on a ground up rearchitecture the rendering engine called Glimmer 2 and I want to talk about that just for a moment. Basically when we built Glimmer 1 we built something that was a nice fast primitive under the hood and we were able to get good benchmarking results but as we started to add more and more ember stuff back into Glimmer 2 Glimmer 1 as we started to make it more and more compatible with ember performance started to slip and in fact performance on initial render time of initially regressed so we actually got worse performance for a lot of applications from Glimmer 1 we got much faster updates right so any update was always like could be like 10 times faster but initial rendering initially was slower and so we the basically the problem that we had was that Glimmer 1 was this little engine that was quite fast but then the view layer core basically what part of ember is considered the core of the view layer actually had all this other ember stuff on top and that ember stuff wasn't that well integrated with Glimmer itself so we basically added all this stuff on top for compatibility and the result of that was that we ended up with a not amazing not amazing performance for the whole unit so if you pulled out Glimmer 1 on your own and used it that's great but it's actually pretty hard to use because it only has a small subset of the whole of the whole ember and for example Glimmer 1 had no component model at all right so in Glimmer 1 if you want to use a standalone you have to build your own component model whereas the Glimmer 2 idea was to say okay what if we can take the view layer core and make it a standalone library that includes all the stuff that you're used to and that includes things like I said like the component model right and that basically allowed us to take the whole performance perspective into consideration when we built the core and make sure that when we start to integrate ember we're not going to see massive performance regressions and what's happening with Glimmer 2 right now is that the work is happening in Canary you can download it right now and check it out at your convenience however please make sure that you run a production build Glimmer 2 actually has even more error messages even more assertions in Glimmer 1 so if you run a development mode it's quite possible that there's all those assertions in development mode will slow down your app make sure that you do any benchmarking in production but this work is already happening it's already in Canary and Glimmer 2 progress you can check out this is the pre-flight checklist for Glimmer 2 it's actually we're getting down to a small number of things and hopefully we'll soon ship an alpha of ember that contains the Glimmer 2 engine we're getting really close it's not gonna we're not gonna go that feature right now because of the fact that 2.8 LTS is coming right now and we would not want to ship a wholly rendering engine in an LTS release that would seem ridiculous so we're not gonna ship the Glimmer in 2.8 so perhaps in 2.9 depends a lot on how people's testing goes once we actually start chipping alphas but we're pretty excited that an alpha build that is you know you can just drop into your app and test your app is should be coming pretty soon now Glimmer 2 as a feature is very exciting in terms of the rendering performance that it gives us but I want to turn it over to Tom to share you with you a project that he's been working on using Glimmer 2 so I want to show you this project I've been working on for the last few weeks this is an app that we're building for the company I work for called Monograph and this is an application that is designed to be shared on social media by celebrities politicians and other people with a social media following this is what the app looks like you can visit this URL online you can check it out right now please I invite you to try it on your phone we call this an MCAST and it's designed to deliver this instant loading native feeling app on the web so this is an app for soliciting donations for Hillary Clinton and it plays this auto plays this video full screen and then a few seconds into it what we do is we pop up this little sorry for Donald Trump so we didn't elect him yet we didn't elect him yet so we pop up this little screen and you can scroll and what you can see here is that I can donate to the campaign without ever having to interrupt the video that I'm watching and so this is just one example this is not an official thing although we are pitching this to the Hillary campaign this is just an example of an MCAST that has been configured to collect donations for Hillary and the thing about this app is that it only has one page so a router is overkill the only data that we have in is the streaming video and the only data that we have back out are our analytics libraries and the Stripe API so Ember data and other services are kind of overkill and this is really designed to be used the big reason we want to use this is because it's designed to be used in the context of a social media application like Twitter or like Facebook so the idea here is that we can go places that native apps simply can't go inside a Twitter or a Facebook web view and still have this very native like experience so we knew that for that goal the most important constraint for this app was load time it had to be as close as to instant as possible and and really Ember is just too big for this use case but at the same time we didn't want to give up on the productivity we were used to and I'm sure as probably many of you have experienced once you get used to that productivity boost that the Ember ecosystem gives you going back to roll your own feels very painful all this work that you forgot that you used to have to do now you're having to do it by hand so here's how we built it we started with Ember CLI because it's the best built tool that we know of in the space we pulled out Glimmer 2 and we didn't use Ember JS and we didn't use any jQuery so this was a raw Glimmer 2 application and because we leaned heavily on Ember CLI tapping into the ecosystem was really easy we were able to take advantage of the performance work that had already been done for us so for example in this app we used the broccoli appcache plug-in to automatically generate an appcache manifest that's literally one line of code in our block file we also added SAS compilation for a CSS appcache support like I said and we were able to transpile it into typescripts with just a few broccoli filters so it was really remarkable how quickly we were able to compose all of these different pieces into a real production application using Ember CLI and what's nice about this is because it's so slimmed down we get really good time to first paint even on older Android devices so this is like on a Nexus 7 running Chrome on a simulated mobile 3G network which is like a three-year-old device right pretty old so rum first paint is half a second just to give you a more visceral sense of what this feels like here's the video from webpagetest.org remember this is a few years old Android device on a simulated 3G connection and so we see usable UI in about a second fully rendered in under three and this is without any server-side rendering which is an additional optimization we are interested in exploring so I told my boss that I wanted to use Glimmer 2 for this project but even I knew that was a risky proposition because no one had really done this before and Glimmer 2 was designed first and foremost as a way of speeding up existing Ember apps it wasn't really designed to be used standalone and so I told him okay listen let me hack on this and if I can't build a working prototype within a week we'll just abandon it and use something else we'll use React or vanillaJS or whatever and so thankfully after a week of hacking I actually did have something working the broccoli stuff like the build script that was actually the easiest part and I was pleasantly surprised to discover that not only was it fast we actually hit our payload size target so our payload for this app with Glimmer 2 is 39 kilobytes and React just by itself is 44 and another thing that's pretty cool about that is that 39 kilobytes include the app and Glimmer 2 under the size of React by itself so one thing to note here is that a big part of React of course is event handling which we don't end up needing in this application and Yehuda and Godfrey are working on even further file size optimizations to Glimmer 2 this is basically the non-optimized version but we think we can get this file size down even smaller and what's cool about this is that once all of this infrastructure was in place I was working with my teammates and we had an experience that while it was significantly pared down it would feel familiar to any ember developer so my teammates Will Bagby and Hasan Abdelraman were able to quickly add functionality like here's an example of Apple Pay support in iOS 10 that we added so you just tap this you pop out the screen and now you can make your donation using just your finger which is pretty cool the web payments is going to be huge it's almost scary how easy it is to spend money on the web with this stuff and when I say ember like experience here's an example of a handlebars template from our app and I think that this would look familiar to most people in the audience so we've been working hard on real apps that have to run on real mobile devices so my experience from extracting Glimmer from ember was a very manual process but I think it shows that smart enough build tools should be able to do that kind of code elimination for you automatically producing file sizes if you use fewer features and over time I think ember is going to become more pay as you go so I'll let you who to explain what steps we're taking to ensure that all the apps that you've got today can benefit from these improvements so remember that our goal here is to let you write one ember app a single code base and let ember create optimized versions of the app the initial content without any JavaScript at all the smallest JavaScript payload that you need to start up interactions and background loading your entire application once the interaction is started up for better network resilience so what are the steps that we're going to use to get there so first of all we need a way for every unit of JavaScript to clearly state its dependencies in order to reliably tree shake the initial load and as you know your ember application already uses ES6 modules already declares its dependencies using ES6 modules but in order to take maximum advantage of this technique we have to use JavaScript modules everywhere throughout the ecosystem such as all these packages that we use internally in ember and the work to transition ember's core and dependent modules is ongoing it's been ongoing for some time now and it's proceeding quickly another thing that we've done here is we've used TypeScript in Glimmer 2 Glimmer 2 was the first ember project written in TypeScript and it really demonstrated its value for core parts of the of the code base there are two major advantages that we got for Glimmer from TypeScript the first one is that the the type system made it easier to define clear public interfaces as an API pretty early on while still retaining the ability to iterate quickly and refactor so we were able to say you know we're not going to hard code this piece of code this other piece of code we'll use an interface but then if we discover that we need a different interface TypeScript and Visual Studio code allow us to quickly find all the places that are using that old piece of the interface and fix it and that allows us to use more interfaces and fewer concrete classes which makes it easier to write code that can be easily pluggable and the type system is also pretty aligned with the requirement the performance requirements of modern JavaScript VMs making it easier for us to encode requirements into the types that cause us to avoid common deoptimization foot guns and so basically these two things together make it a lot easier for us to build things like standalone standalone glimmer in a way that performs very well and is also pluggable in whatever environments without having to worry about the things that have historically made big monolithic libraries the way the normal way that you build tools like this you if since you're looking at a TypeScript slide you might be wondering so TypeScript and Ember what's the story with that especially since you know Angular has really bet hard on TypeScript and we definitely want people to be able to use TypeScript in their applications but we are going to continue to design Ember as a JavaScript first framework and we want to make sure that JavaScript is forever the happy path for building Ember applications so TypeScript itself of course has the philosophy of being a gradual type system a type system that you can add to existing JavaScript code bases to get more rigor and going TypeScript first kind of the opposite of that philosophy right it says use types first we want to use TypeScript for what it's good at which is adding gradual typing to parts of your code that you think could benefit from types and that's how we're going to think about using TypeScript going forward I've also been working in my work on TC39 very hard to standardize more stuff in classes and decorators in JavaScript so today here's what a component looks like in Ember and the fact that it looks like this means that there's effectively a whole object model that you have to download that Tom's code didn't have to download because he didn't use the Ember object model here's what a component looks like today and here's a hypothetical version of the component refactor to use JavaScript classes and decorators to write the same thing Robert actually has a plug-in today that you can install to get something similar to this but clearly this is still speculative and the decorator feature is still experimental in JavaScript itself by moving the object as much of the object model as possible into the language not only do we get to remove huge swaths of code once you migrate to the new syntax so I don't mean we're going to delete this code from Ember of course it's important that you have a migration story but in the sense that we can remove code that you're not using we can start removing the object model once people migrate once your app migrates to it but it also means that app developers are more likely to be familiar with the code that they're looking at already instead of looking at a whole new thing that is the Ember object model like I said this is going to be an incremental change we're not going to break your apps and we're going to make sure we have a story for moving piecemeal to the new syntax but I think this is definitely the a story going for it so despite all of this I think that there's kind of an elephant in the room which is that even if we make the file size of a simple app tiny people still feel overwhelmed when they're learning Ember so if they succeed in learning it they usually love it but a lot of people don't even bother trying because it feels so intimidating often they just get dropped in the deep end of this API surface area and they feel like they need to understand everything just to get something simple done and I just think that when you give someone an abstraction and they don't understand it it's actually worse than useless because that makes it much harder to learn and they feel like they're fighting against it and so the solution to this typically the proposed alternative to this is kind of like a build your own framework approach so we say we're going to start with a small core like backbone or react and then we're going to layer on the abstractions as you need them and this feels really great at first but it has some real shortcomings first you have to integrate these disparate pieces yourself and that glue code that bridges these different libraries can really add up when they aren't designed to work together and it gets worse the more libraries you throw into the mix there's kind of this combinatorial explosion of complexity and second when you have too much variation in how your apps are architected you can't actually build automated tools that slice and dice and optimize optimize your application in different ways it would be like asking GCC to compile and optimize your program when every app was written in a little bit different syntax so react I think is obviously used by more sites than Ember but I would bet that Ember is more popular than any particular permutation of react redux flux mobx and the other various libraries that you end up using in practice with a react so for example let's look at what one hypothetical web app stack might look like built using the build your own framework approach so we're going to start off by having a build tool right everyone needs a build tool from building a modern web app now we're going to add react because we heard that's pretty good but we also heard that react is just a UI it's just a V and MVC so we're going to add some state management using redux we need to add redux storage to store our state I guess now of course we want to take advantage of the latest features in JavaScript but we need to support older browsers so we're going to throw a babble on here and of course we want to get the best performance out of our app and we all know what the root of all evil is so we're going to add immutable js next we need to add routing of course because we have multiple pages so we'll throw a react router in here that doesn't actually communicate out of the box with redux so we need to wire these two things together but thankfully there's a module for that that does that for us automatically we need to internationalize obviously and support many different languages so we'll add add a react intl in here we need to add server-side rendering to support Google and is to make our pages much faster for our mobile users so we'll add express for that we'll add format js here free format js does but it's definitely related to Intel ah yes formatting dates and stuff like that okay so that's great we've got our app also we'll need to add react helmet to make sure that we can put our react components into the head we'll need to add a gulp plugin for our favicon we'll need to add raven js I think this is for testing short id to generate these client-side id's of course we our designers are writing their css and safs so we'll need to add that and then we'll need to add auto prefexor to make sure that this works across browsers without having to add these add these prefixes so that's pretty good and then you know it we'll add mocha for the tests and we'll add bluebird for the promises and we'll add validator js just to make sure that our forms are valid and then we need to make sure that the code we're writing is legitimate so we'll throw eslint in here which is great and then you know why not we'll just throw on webpack here to help bundle up all of our files and our modules and then we need to make sure this runs in the the server so we'll add webpack isomorphic tools I believe is what the scientists call it now I know what you're thinking you're thinking he's just trolling no real app would actually end up with something like this but actually this is based on a real react boilerplate I found called este and if that is not your liking if you feel like that's too big I also found that there is a site that aggregates all of these different react boilerplates available and this is this is a great resource if you're getting started it has a ton of stuff on it in fact there's actually more but keynote has a maximum animation distance of 10,000 pixels so this is all let's see and actually this one's my favorite it's just like the point you've just given up on life this one's going places I think it has 57 stars yeah it's going up okay so this is not to to pick on on any of these projects the bottom line here is just that it's nearly impossible to build tools that can optimize the delivery of an app when you have this much fragmentation in how they're architected so being able to deliver these different versions of your app at different times to kind of bend the curve of trade-offs between progressively enhanced web apps and native apps requires that the tools understand everything needed to make your app tick from rendering to app initialization to data fetching and that's why all of the work that we've done as a community to build shared solutions is so important because any of us can improve a piece of ember and be confident that that change will reach the rest of the community and that means that we can build higher together instead of technical debt this is almost like technical compound interest but we understand that not everyone wants to start with the full ember stack and so it's a major goal for me and Godfrey to make Glimmer as a project easy to use as a standalone library optionally with Ember CLI as Tom used it there are many use cases for this from writing reusable components cross framework UI components to incrementally retrofitting older server side web apps that cannot be rewritten we can let people enjoy the benefits of Glimmer but most importantly as your app grows we'll have a cohesive community supported path from standalone component to page to app every step of the way so there's kind of an interesting thing happening I think which is that React is focused on this kind of radical simplicity in fact I hear people describe react as not even being a library for building web apps it's kind of a library for describing UI components that happens to have a DOM adapter and on the other end of the spectrum you have Angular 2 which describes itself as a platform of capabilities supporting JavaScript TypeScript Dart cross platform development with react native and types with react native and native script integration a new CLI tool a new data library a new router built in RxJS observables and more and so for the first time Ember is positioned in the middle of the field that's never happened before and we're not trying to solve the problem of cross platform app development we're just trying to give developers the most pragmatic solution for building apps on the web we think of Ember as being the SDK for the web it's all the tools that you need to build great web experiences and we don't want to be a platform we want to be an SDK for the platform you already love an SDK that helps you manage complexity and helps you deliver the instant on experience users expect in other words we want to build the solution that doubles down on the web strengths we believe that web apps are not just good enough they have real advantages over app store encumber and applications we have a productive well thought out framework with a vibrant community we don't need radical change or to try to turn Ember into the dominant paradigm for writing apps for all platforms what we need to do now is to focus on speed size getting new developers started and reaching new audiences that couldn't use Ember before me and Tom have always said we want to build a framework that would last at least a decade or about half a decade in now and we could not be more excited about the future of Ember and the future of the web so what I would say to all of you is let's all build higher together thank you very much