Thank you all so much for being here for another EmberConf 2017. You can see this is a really big group, which is really exciting. We have such a vibrant, awesome community. We're back to one track this year. So can you raise your hand? Who was here last year? All right, I really like one track, because it makes us feel like this really awesome community together, and I'm really, really excited to be back. Also means that all the talks are good for everybody, which is good. So I have some announcements. First of all, you probably are aware that there's a live stream since there was a slide up there about it. You should tell your friends, et cetera, but also probably try not to be a bandwidth hog while you are in attendance. So first of all, probably don't look at the live stream while you're in attendance. That should not be necessary. Disable your Dropbox. But second of all, disable your Dropbox and anything else that might be happening, just because there's a limited amount of bandwidth you can look around them. Sir, are you in the front? If you could turn the BitTorrent client off, please. Yeah, so there's that. And then the other thing I want to say is just there is a, EmberConf has the code of conduct. It's actually important that we follow it, but I just want to give a personal, personally how I feel about it. So I personally grew up as a Orthodox Jew, which is a religious minority, and I've had a lot of experiences throughout my life. Hello, there we go. Where I've been in a room and someone said something that they didn't think that much about, and I just felt like, oh, I really don't want to be in this room anymore. I really wish I could escape this room and be somewhere else. Usually not, again, not because someone was on purpose saying something bad, just the situation that I was in. And I think in general, the way I think about codes of code of conduct and being good to your fellow people is if you feel like you're in a situation where that is happening, either as a participant or as a onlooker, if you see somebody who looks very uncomfortable because there's a thing that's going on that probably nobody intended, but is causing someone discomfort, try to do something about it, you can be nice, don't necessarily assume that someone's doing something on purpose, but also try to help people feel comfortable in their, in situations. So, and in terms of the logistics, their website has the full enumeration of it, and if you feel like you need to report something, anybody with a staff shirt, like the red staff shirts I think, are they red this year? I don't know. Green. Anybody with a green staff shirt is around to talk to you. You can also email the email that's on the website. Definitely they are here to help you if there's anything that you need help with, so don't feel shy about enlisting their help in any situation that might require it. Okay. So, we are here, as Tom said, where it's our 50th year here, I was actually preparing a bunch of slides just about the five years that we were here, and I actually thought it was pretty cool that pretty much immediately after we got started, we already had pretty good art. So, like the whole five year, the whole five year spectrum has like cool, cool art. So, I don't know, how many people remember this blog post? A few people. So, the beginning of Ember actually was, we had, we were doing Sproutcore, and there was a convention that every new project that Sproutcore made had a beer name. I don't remember any of them, it was like BitBurger or something like that. I don't know any parents. Yeah. So, we internally called Sproutcore to Ember, and then we had talked about that in public a lot, and we were like ready to go ship it, and so we announced Ember.js, and people were like, actually there's a small talk implementation written in JavaScript called Ember.js, so you can't have that name, and we have to rename it very quickly over a few days, which we thought was silly, but whatever, it seems fine. So, anyway, this was the very, this is basically the beginning, this is the birthday, December 8th, 2011, the day that we'll live in. And here is what an Ember app used to look like in the very beginning. This is actually what the Ember 1.10 documentation told you an Ember app was, but some time has gone by since then, but you can see that there was like, Ember at the time was very much a product of its time, right, you had a script tag, the way you created handlebars templates as you put them in a script tag, and we didn't yet have a pre-compiler, so you just, things happened on the fly, et cetera. So we were kind of in our awkward teenage years at the time. By the way, this is not official art, but I looked at them like, this should be an official thing, they should make this cartoon, it would be awesome. It's Fry and Lila's Children. And basically at the time, there were a lot of things that were very awkward about Ember, like in order to type attributes you have to use bind adder syntax, and there was this thing, I found a lot of blog posts that I'm very happy I didn't find at the time when I was doing the research for this, so this guy's like, Ember's great, it's so easy to use, but then I looked at the DOM inspector, and oh my God, it's like a disaster. So in the beginning, the way that we dealt with bound properties, because of the fact that we had a string templating engine at the time, was to use these script tags, which had the nice property of being allowed to be anywhere in the DOM, and had the very un-nice property of looking terrible in the DOM inspector. So there were a bunch of things that we did in the beginning that are like kind of ancient history, probably a lot of people in this room have never seen or heard of them, but were kind of there at the beginning when we started doing Ember. So here, just like a quick whirlwind tour, so 2013 was the first Ember camp ever, we had like camp mascots, and Tivaris had this great podcast Ember on air that we made a Thomster for him, and actually the left thing there is the original Thomster illustration just came from like we asked Lindsay to do some design work for us, like hey, can you make some illustrations for the front page, and the thing that she gave us for productivity was so good that it became the mascot for Ember, which is pretty cool. And 2014 was basically like, we started to get into the swing of things. Actually it's worth noting, 2013 when we did Ember camp was like two months after that Ember JS announcement, or like three months, so we got up and going pretty quickly. And so we at like 2014, we had another Ember camp, we created the release channel process, we added some features, you can see here, not very important the details, but we like, at that point, we didn't yet have the log helper, and we didn't yet have, like the each helper didn't have that, like block syntax yet. And we, in 2014, we killed MetaMorse, which I'm still very happy about, and I'll find that out also. 2015 was basically, it's a sugar pirate, Tomster. And by 2015, like, oh, we had a lot of user groups, so that's when we started really getting the Tomster decks, so many Tomsters. And we started, I think 2015 is probably the beginning of when you would consider modern Ember, like we started talking about fast boot, we didn't start implementing it really yet. We started working on HTML bars, we talked about Ember 2.0, and just in general, like the Ember project, including things like Ember CLI started to be a thing. And there, some more features happened, like it actually was hard for me to winnow down the exact list that I snippeted here, but like for example, indexes in each loops were a thing that was like a highly desired feature before we did it. Thankfully, it is not anymore. Like now it's just taken for granted, but it was a thing that took us a long time to get right, and like the component helper, things like that. And we killed by an adder in 2015, which is great. And we also killed object controller and array controller in 2015, which is also great. And then last year was, we introduced Zoey, which is great. This year we're introducing Zoey as a life-sized mascot you can take pictures with, so you should do that. And I would say like 2016 was probably the beginning of the era that we were gonna be talking about today in the keynote, trying to get more rationalized about what it is that lives underneath Ember, right? So the first few years of Ember, we were trying to figure out what is an Ember app at all? And last year we started thinking about like, what are the building blocks that make up an Ember app and how can you start reusing them? So app.visit, for example, is an API that lets you build things like FastBoot. Not everyone who's doing things like FastBoot or is using FastBoot, they can use the primitive that we built that we put into Ember. There's things like contextual components. So we started getting more rationalized about what it is that we're doing and that is really what we're gonna end up talking about today. So we introduced Zoey, we also got Glimmer landed. We started using ES6 features like weak maps, if possible. And we also started doing the LTS releases. You can see the lovable LTS mascot, Lumster on the bottom. So we started doing that. So last year I would say is like really we matured as a project. A lot of the things that end up being important about Ember now are what we did last year. And we also killed the render helper, which turned out to not be very important but hadn't lasted for a long time. And so this year I don't have any photos because we're not here yet. I mean, we're here now. We are now, yeah, here. I could not any photos yesterday for today but this year our activity mascot for EmberConf is Thomster and Zoey on a bicycle. It's great. And also this year user groups are allowed to commission Thomsters and now they're also allowed to commission Zoys if they want so they can choose between Thomster and Zoey as their official mascot, which is pretty cool. Before I move on to talk about Ember stuff, I want to talk a little bit about the core team. There's the usual core team announcement stuff. So this is the core team last year. It's, we added some people but I think last year was paused more or less in the composition of the team. I think we added Igor last year. Such a good team. I can't remember. Yeah, I don't remember. After a few months go by, I'm like an old man. You who hasn't also slept in three days? I also haven't slept in three days. So this is a team last year. There's a thing that we are going to start doing. Trek who was one of our early, what we're not calling emeritus came up with a point. So we used to call these things alumni but Trek pointed out that actually emeritus in general are actually still pretty active. They're just not doing necessarily the ultra day-to-day activities that people are doing all the time. And so it's not like alumni in a school where you went to school and then you stop thinking about it ever again. It's more like an emeritus professor where you're still proud when people can talk to you, you have people respect you but you're not necessarily required to teach classes anymore. Core team at large. So basically that actually reflects reality. For example, Mocti is giving a talk today about Ember concurrency which him becoming an emeritus gave him many emeritus professors and it's time to focus on something that was a passion of his. You're saying he couldn't do both concurrently? And I think in general that is sort of our... That is set time out of it. That is, that's sort of our expectation is like, we don't want to have to wait until someone like completely left the community to notice, oh you're actually no longer around. But rather like once people start becoming more interested and more focused off or generally are not able to do ultra day-to-day activities then we honor them with emeritus status. So this year Eric who was actually like, I think either the first or one of the first contributors to Ember and who's always sort of ran his business through on Ember and talks to a lot of people through trainings and stuff. He always represented the voice of the user and continues to do that actually. He is going to be honored with emeritus status and the flip side of that is that there are three new core team members. Katie Gengler, Chad Hytala and Ricardo Mendes. You probably know Ricardo Mendes as locks. So just quickly, Katie does Ember Observer which means she has somehow a superhuman effort read every add-on and turns out to be a good quality for a core team member, someone who has read every add-on. No, but she's great. She's done really awesome work. Chad has done a huge amount of the heavy lifting behind the scenes on Glimmer for like a very extended period of time. It's got the scars to prove it. It's true. And locks has also been doing. Locks is our 24 hour slack bot. Exactly. But it turns out also is a human. Technology these days is incredible. Yes, and I would also add that locks has a strong passion for paper cuts and like just pairing down both the learning experience which she is one of the leaders of that team and also just in general has focused a lot on trying to reduce paper cuts in Ember and that's good to have someone focusing on that in general. So that's the new composition of the core team. Your core team. Let's give her a round of applause so all these people work really hard. So before I, since we were talking about like it's been five years, I just was doing the nostalgia tour slide deck and reminded myself of what it looked like when we started. So this is the thing people talk about like oh you know you have these frameworks that were around a long time ago and maybe have some baggage from that time era. I was like what did it actually look like when we first put code down for Ember 2.0 May 2011, what did the web look like? And it actually was a pretty abysmal place from the perspective of today. Like nobody actually shipped ES5, let alone ES6. No browser implemented Flexbox.  And there were features that I think like everyone comes takes for granted as like obviously that is important like query selector all which actually at the time like everyone used Sizzle because or some library like that because the web just was missing core features. And like at EventListener which probably everyone was like oh that is obviously an important feature on the web was not actually standardized at the time. Internet Explorer which as you can see was a dominant browser had its own event implementation that you had to use if you wanted to target those browsers. So as you can see there was a lot of it was not a very hospitable place to build stuff and yet that is the reach upon which we entered. It's funny right because people think they say offhand the frameworks like oh yeah these frameworks are from an older generation and yet at the same time people today treat IEA like it's just a bad dream right? Like it didn't even happen but and yet you look at this and like actually everything we did had to be in service of IEA because it was by far the slowest and least capable browser we did. Right so. I guess we supported IE7 also but that was at that point already. But yeah IEA turned out to not add a lot on top of IE7. But yes exactly we were basically forced to do a lot of things in that era just to deal with these very dominant but very in modern terms derelict browsers. So in contrast today like all basically all those features have been completed and exist in all web browsers that you target and there's some new features. So there's some things that you have come like that you probably know about like page visibility or media queries that are like really part of the modern toolkit and have already shipped in all browsers. I put border radius and box shadow here because it's just like a thing that at the time was oh when can we have border radius? But now like every new web developer does not have to worry about making rounded corner pings that you have. I really enjoyed slicing them into. Pings is not a thing IE6 did not actually support transparent PNG so. I think it had like a dash MS filter to enable that. Yes there was some hack. But anyway that stuff is standard now it's like part of the toolkit it's like a whole set of things that you don't have to think about and there's even like newer features coming like service worker which lets you intercept network and WebAssembly which lets you target very low level native things. Both Safari and Edge actually have shifted in technical previews so like basically WebAssembly is here more or less like already shipped in Chrome and Firefox and is almost here in other browsers. That's like a pretty amazing difference from what the web looked like in 2011 when we started so it is actually valid to say things have changed the world like web frameworks should change with those things. What's really incredible I think is that there are Ember apps from that era that are on the latest version of Ember today. Yeah so like Skylight the app I work on we started in 2012 and is on Ember 2.11 or whatever the most recent version of Ember. We have trained so I never remember what the latest version of Ember. 2.37 I think is the current one. But yeah like Skylight is on the latest version of Ember and there's a lot of people like that and we've been around for a number of years. I just think when you look at the environment it's like moving from the Sahara Desert to like a plush luxury apartment. You know what I mean? It's like you've really dramatically changed your environment. It's only been five years and that's also by the way if anybody ever tells you like the web stands still what has even happened that's like not true. I don't even have anything to say other than it's just not true. And honestly five years is like a very long time in web time right like as we have just seen the world completely shifted and a lot of times I think about the fact that like the Great Recession from 2008 is like less than five years ago right. So there's been things that are relatively recent in historical terms that are older than that five year split. So like a lot of web time works at a different speed than regular time. And like another way to think about all this is like here are the exact the points where various things had one point of releases. Like one thing that's interesting. So Godfrey wrote this blog post. This image came from a Godfrey blog post from last year and like some of the things that are on this I don't even know what they are anymore. Like they have already gone into the sands of time. That was called Sproutcore actually. That's true. One of those is like Twitter fabric or something is a thing. Slight. Slight I don't know how this is a thing. Anyway there are various frameworks here and you can see that even in like framework time it's pretty long. And so of course Ember like started in 2011 we didn't like we don't still have a stream templating engine like a lot of things changed over the years but we were also like pretty early on a lot of the things that we did. So there's actually a lot of areas we were ahead of the curve. Some in some cases painfully ahead of the curve. So like for example we did template compilation ahead of time back when it was like still popular to use mustache and just interpret your like regex interpret your template. Ember CLI like when we shipped Ember CLI the first time it was like many people were like the web already has a build step. It's called F5. Are the advanced users are like I have put all my shell scripts inside of a grunt file so now it's.  We when we adopted the six-week cycle basically Chrome and Firefox were the only people that ever on a six-week cycle. So doing it on a library was like a new thing. We also adopted some like ES6 modules if you were around when we adopted them were not ready like they were still actively being developed when we adopted them. We worked a lot on of course people know our rendering engine and things like fast but we worked on not just like there is a way to do it but it is consistently works throughout the ecosystem with add-ons and everything. And in fact the promises A plus spec came out of Dominic's anger at us getting promises wrong. Yes that's true.  Yeah so exactly. And that arose the promise standard. He wrote a blog post that's like you're doing promises wrong and it was just like a vitriol at us and I was like hey if you give me a test suite I'll make it pass. Right and that ended up being the input into the official promises spec which is now in the browser. Like that is the period of time that we're talking. Turns out standards can move quickly sometimes too. So again it's been like five years that's pretty amazing I think. A lot of the way people talk about this is very abstract. It's like it's been five years therefore it is time to break things etc. But that's like it's only possible for people to think about it honestly because there's a lot of people who are new who weren't even around for that entire spectrum so it's easy to think about it very abstractly and I tend not to. And interestingly like a lot of the cool ideas that I talked about on the previous slide are actually like pretty standard. So if the reason that you like Ember was because we compile our templates ahead of time a few years ago then you don't need to use Ember anymore. It's fine everybody does that. Or even if you like Ember because it has a CLI tool there are a number of frameworks now that are like trying really hard to have a good CLI experience. Right so there's a lot of reasons that people might have liked Ember a few years ago that by now have become like pretty standard fare. I think five years is enough time for an idea to go from being controversial to basically widely accepting. And I would say most of the things that were most controversial about Ember in the beginning have now become accepted through our evangelism and also people adopting in other frameworks. So that may lead you to ask a question like is there another five years in Ember? Maybe like the Ember's role was to be the bridge between 2011 and 2017 and now we're like done everyone should go use something else like React or whatever. And I think there's a reason why people think that there's a reason why people feel like it's time to like Ember is a relic of a bygone era which is that it seems like there's a lot of baggage in Ember, right? So I think there's some sense in which this is just an abstraction. It's like oh it seems like Ember has been around for a long time therefore obviously there's baggage. And I think on the core team we're like actually we did a lot of work to clean up a lot of baggage. There's also a sense, some sense like for example the Ember Algic model that is really, really a relic of ES6 classes not existing and ultimately like will make sense to get rid of and a lot of people like his initial reaction is that seems like impossible. You, it's like intrinsically part of Ember. You have to. Well even before ES6 classes people I remember hacker news comments that were like oh it looks like Java. Yes I agree that people said that. So there's a problem of the innovators dilemma basically which is like I guess we're not popular enough to have the official version of the innovators dilemma but there are 800 people in the room. But there is a problem of like once you have a large number of users it's actually hard to adapt to changing times because you don't want to hurt the people who are already using your product. I mean especially in our community I think that commitment to stability is actually an important thing but it comes with important trade-offs which is that sometimes you have to keep things around longer than you might like to. And so I think it's just natural to ask well what's the end game for that? Yep. And I think we've actually been pretty mindful of the problem and have done a lot to be like to mix things up a lot internally throughout the years but there is still some limit to how far that can take us. So in order to talk about like what's the next like what's the next five years, what are we doing? I wanna talk a little bit about things that didn't work or like things that we tried to do that I think just self-evidently ended up failing in terms of the exact projects that we were working on. So like I think we did a survey of people in this room plus times a few and one of the top things people said is like when are you shipping routable components already? That's common. Also we like tried to deprecate controllers in the 2.0 era and didn't really get over the finish line of that, right? So there's a bunch of things that we did in the 2.0 era that we sort of communicated it was a plan and then I think it's just not controversial to say that by now we didn't really make those plans work.  On the other hand there's actually been a lot of things that actually did work over the past few years and I wanna talk about those. So Fastboot is a project that allows people to server-side render these days for SEO purposes. They're Ember apps and that exists and you can use it today and before today. Engines is a similar story. Engines is a thing that allows you to break up your app into smaller chunks and put them together so you instead of having to have one giant Ember app you can have a few smaller Ember apps that you merge together using engines and that's also a feature that I would say has been successful in Ember. And of course Glimmer itself has been very successful so last year we said like hey look we are working on the basic Glimmer 2 which we aren't shipping yet. You can see that we talked about 2.4 at the time and we actually ended up shipping in 2.10 I think so like some time went by. But we said like at the moment we're already seeing good performance improvements and so we said that in March in July we announced that the Glimmer 2 Alpha that is like a drop in replacement for people's apps and in November we shipped Glimmer 2 as a drop in replacement to apps and basically right like as soon as we shipped it there's this great blog post that I really liked at the time by Micsonic about like what it is to know about Glimmer and like the top thing is like it's a drop in upgrade but as soon as people started using it they saw like very significant performance improvements so without making any changes to your app without any breakage for like 99.9% of patterns you got like massively improved performance and you also got massively reduced bundle sizes and that's like something that you got between March and November we shipped a thing that was basically a prototype mode like already working but not ready to drop in to something that dropped in and saw big improvements and like one of the biggest like thing that gratified me about this a lot was that this course was actually stuck on pre-Ember 1.13 because of the fact that there were some performance regressions that really impacted their app a lot because they had done some handcrafted optimizations and also there were legitimate regressions and they were holding off for improvements and they by the time when they actually upgraded to 2.10 they got like double app performance over what they had seen before so not only were there no more regressions on the 2X branch they got a 2X improvement from what they saw before and I think those things are actually significant because of the fact that you didn't have to there was no breakage it was just a regular 2.X release so that's pretty significant. So just in general that is like the way ember rolls is that there are I think Glimmer 2 was a total basic total rewrite of the rendering engine that came after HTML bars which completely replaced a string-based thing with a dom-based thing and we were able to do that in the structure of a normal project so I think the general frame of like oh like things are changing a lot therefore you are basically forced to like reboot entire projects is not obvious true I said before there's some limit to how much you can do but I think the limit is further along than people expect right so we were able to switch from a different like a pretty different templating engine to the new one without any changes in the API and similarly when we switched to what was then called ES6 modules and is now properly known as ES2015 modules that was also like we switch from a global's mode where people are writing like app.whatever equals whatever to ES2015 and people were able to use a hybrid like what we call a hybrid resolver to migrate incrementally and these days like everyone like ember is actually one of the earliest adopters of ES2015 modules so we didn't end up getting left behind in global's mode despite the fact that we started off in global's mode and just in general I think ember2.x as a series has done much better than the very annoying breakage period of ember1.13 right so I'm sort of saying there's a mea culpa here like the ember1.13 era tried to do a lot of upfront design tried to do a lot of things that involve breakage we were we ended up not it wasn't like a total fail because of the fact that we were technically pretty good about deprecations I think ultimately people wanted the benefits that the 2.x era provided but there was definitely a bunch of stuff that didn't work so well around the 2.0 era and I think the 2.x era has worked better in general so I just basically gave you juxtaposition between two things some things I thought went well and some things I thought didn't go well and like what is my opinion or our opinion about what we learned from that those eras first of all this is like sad to have to say that we learned this because everyone already knows it but somehow it's a mistake that even the best of us make basically big upfront design like trying to design a new feature like angle bracket components or ratable components like something significant completely before any implement any users are able to access it is and such that it is locked down once you get it out of the gate right so if we say here we have now come down from the mountain with the stone tablets that tell you what ratable components are the chances of that succeeding are actually pretty low and I think a lot of the what a lot of the two O era mistakes have in common is that we tried a little bit too hard to design things upfront now we have a great community and RFC process allows people to help participate in that design but ultimately design that far precedes usage is not a good design process I think we just end up crashing on the rocks of backwards compatibility and our stability guarantees and so there's this problem which is that the people we can't land it until it's something that we feel very confident in and so in the meantime it's kind of just sitting around but no one can use it and there's no there's I think the Ember ecosystem in general has suffered from a lack of experimentation there are some areas where there's been a lot and I'll talk about that more later but there have been some areas where it's just been very difficult because of the fact that we don't expose anything and we're like building towards a glorious future so I think in general that didn't really that whole generally that kind of thing that doesn't work it didn't work and you should probably say something if you see it happening again there's a different approach that has just generally worked a lot better for us over the past year or two which is instead of like designing a feature like engines upfront and like making it perfect and then landing it or even making like an MVP perfect and landing it I think fast food is a good example of this what we landed in Ember is just a visit API all the visit API lets you do is programmatically ask Ember to go visit a URL and give you back the sorry the DOM element that came out of that and then you can do whatever you want with that so that's all we have to put into Ember and that's actually not a hard API design it's low level most people aren't interacting with it and it has a reasonably well bounded design and then on top of that we built fast boot as an external add-on that anybody could use on top of the stable like release builds of Ember but that thing is allowed to change like that thing has its own stability story as it's iterating and sorry and like other people like LinkedIn actually uses the visit API directly without even using fast boot and people could plug in their own server infrastructure on top I think the point with server side rendering with client side apps is it is a brand new thing and we're all learning how best to do it and if you think that you have a better way of doing it you shouldn't feel like Stymied you shouldn't feel stymied because fast boot isn't moving fast enough where it uses Express and you're really like a very happy happy user you can do it now right you have the tools you have the same underlying primitive that we have so in general like both the engine API and the fast boot API were things where we figured out what small things we need to add to Ember to allow experimentation to happen elsewhere we also aren't just like throwing you to the wolves and saying do the whole thing yourself we're giving a pretty good initial reference implementation that probably eventually will get merged in in some form but we're also totally fine and happy to have people try other stuff and in fact in both cases people have done that so I think that's sort of a new way that we're thinking about approaching design in Ember however when we actually add new features to Ember like Glimmer it is important that those features not create forks so even if technically you can have a compatibility story like you opt into Glimmer and then you are like forking the universe and you have a completely different rendering engine or something like that it's actually important to us that when things get added to Ember like Ember proper that stack overflow that documentation whatever reflect a mainline way to do stuff so when we're doing a big internal refactor like Glimmer we Glimmer one actually just suffered from there wasn't a good enough compatibility story and I think from now on whenever we make big internal refactors we're not gonna make big breaking changes anymore so I think the summary is like experimentation is a key way that we all evolve as an ecosystem so there are things like I should be clear by the way this smiley face and frowny face is not passing judgment about the project it's about how many hoops the author of that project had to jump through to get their job done so Ember Redux and is built on top of the basically the object model story in Ember of course it doesn't use the Ember object model but the fact that the shim between Pojo's and the template layer is well-defined in Ember means that it's not very hard to implement Ember Redux Ember concurrency, Ember orbit are also are all Ember Ember orbit is built on top of the same shim that Ember data uses right so basically all these those three things use fairly well-defined APIs that exist already in Ember that you can use to experiment Godfrey actually gave a really good talk the first Ember conf about experimenting with those things he built a hacker news reader that use like HTML as a data source and things like that some APIs that are actually great and have a lot a lot of experimentation but then there's other things like the component API which is quite locked down and that means that people who are implementing innovative things in the component space end up getting have to use private APIs that break and means the experimentation is not so stable so really what we learned from the last couple of year like the last couple of years since 2.0 is experimentation is very important we don't want to break back compatibility willy-nilly but we need to do more to expose the primitives that make the system work so that people can try other things and don't lean so much on doing everything up front so some things that are actively happening along these lines are angle-backing components which is a thing that you probably have heard of at various points and like want for good reasons we'll talk about that more also later is a feature that kind of suffered from the fact that we had we felt like we had to we had a one-shot chance to replace the existing component model with a new component model so let's like get it perfect before we ship anything and even though we were like always targeting an MVP there's just so many questions about how you want to model it that meant that was very difficult for us to ship anything and that's roughly what happened so you should check out Godfrey's RFC which I have a link to later on in the presentation but there's a picture of it here if you want to look very closely binoculars but basically the way we're doing angle-back components is that we're talking we're implementing a low level custom component API that is it's not just it's not like it's a function have a nice day it's basically like sufficiently rationalized to talk about most of the things that Ember components already know how to do like life cycle hooks and things like that and templates but it's low level so you can implement lightweight components and ideally angle-back components as well so the idea is that we're going to start doing the same story we put up we design a primitive the primitive has less ergonomic pressure on it and then we let ourselves and other people do experimentation outside of core and then another thing you probably have heard of you like there's a new version of pods called which is sometimes called module unification which is just whatever the technical name for it is in the RFC but basically it's a way of allowing you to put components next to the other components next to the components they're nested into helpers next to the components that use them components inside the routes that use them that feature used to be called pods that also went through a pretty low level RFC and it's now like it's going to become available through an add-on that allows you to have a have both worlds in the same thing I actually don't I want to have a slide with the two lines of the code you need to write to make that work today but I'm sure you can tweet at Robert and he will probably reply to all of you but basically it's the same story right we don't want to have to we don't want to have to wake everyone wait for the feature to get the high-level feature into the into the framework so we're trying to expose more hooks that let people do experiments but not but also we're doing a lot of the work just in a way that doesn't put as much pressure on stability with that said like probably the biggest thing along these lines like the biggest active work item is glimmer 2 and I want to of course want to talk about that today because active work item and I'm excited probably so are you so I want to give a tiny recap of what cause glimmer to exist in the first place and I think it's easy like it's easier to understand the story based on what I already just said about what was going right and wrong so I think we only really did the postmortem now about 2.0 but I think we started throughout the last year thinking more about the exact problem of primitives and modularity so when we started working on glimmer what we noticed and we talked about this last year is that the boundary between ember and the templating layer was actually not very crisp so there was a lot of things that just ended up on one side or the other for no apparent reason and that the real consequence of that is that ember itself ended up pulling in a lot of random view layer templating engine concerns just because of that's where it happened to land in the world and so the exact boundary between ember and html bars was very unmodulated was not very clear which meant you couldn't like take html bars and use it in another project very easily um so the glimmer project was really about extracting the things that were generic like yield for example in a template is actually a very generic concept and extracting that out of ember and putting it into a separate library and really leaving ember's job to be high-level ember features and compatibility right so there are some features like outlets and last year the component helper although now that is actually extracted into into glimmer but basically any features that are like pretty coupled to how ember tends to work exactly how embers object model interacts with glimmer those things are in ember but glimmer itself has is now a really general purpose rendering engine and importantly because that is a very large magnitude shift right that is a significant internal change um i think in practice every single line of code in ember that have to do with the view layer in the last two years has been replaced at some point by three times probably a few times in some cases so in in order to buffer people in this room from those pro changes but also give you the benefits we beat the ember layer is basically the thing that gave you a consistent api so that ends up that ends up being very important right i've said this a few times but making 2.10 drop placement for 2.9 is a significantly better story than 1.13 not being a drop in replacement for 1.12 i think that's obvious but i think for people who are here for both the story was very different even though i would actually say 1.13 is closer to 1.12's implementation than 2.10's implementation is the 2.9 we just worked a lot harder on compatibility because of how much the breakage didn't really work out as more problems than we expected and it all sounds very silly in retrospect and i would also say that tests one of the things that made this work is that when we did 2.10 when we did glimmer we made sure that tests the testing suite ran on both the old engine and the new engine unfortunately as you probably know from having written tests there are plenty of tests in the world that are accidentally coupled to implementation details that are not part of the public api so we act we did a huge effort that the community probably a lot of people in this room helped with which was just to take tests that were accidentally coupled to some implementation detail and upgrade them to be more um... general so that um... so that when we say you know how does an if statement work it really is testing out if statement works and not some detail of how the view layer used to work like the view system in number 1.0 so the community really helped with this i think it would actually have been impossible to ship glimmer if we didn't get a lot of help from the community on upgrading the tests and it was actually it was not a trivial automatable job there was a lot of detail work in it the community helped a lot and I basically want to give everyone a round of applause for helping with that because I couldn't have done any of this without that help and i just want to say like bluntly like from now on this is the process that we use for engines for fast food for glimmer is how we're doing it from now on we're gonna not lean on breaking changes we're going to not lean on big upfront design and we're instead going to lean on small primitives and compatibility as our as our main mantra for how we do new feature design so just to give people an update on what's been going on since we've been talking about glimmer i want to talk again about how the glimmer vm works because it gives you some context so uh... first of all the general problem that glimmer is trying to solve you don't need to read all the text on the slide uh... the general problem that glimmer is trying to solve is that there's actually two problems in web application design that are in conflict with each other so there's like sixty fps jank or like if someone wants to be fancy like main thread stall i sometimes see this on twitter uh... that is one problem like you're trying to be very interactive to users once your app is going and then there's another problem which is like how fast can i get my app going in the first place or what is the time to first interactivity or sometimes called boot time uh... also is very important people care a lot on the web about it and both of those actually are in like computer science terms real-time constraints right and if you are building a financial transaction system you have a real-time constraint you need to respond very quickly but you're willing to spend like infinite time on boot up to get to very very fast response of time once you're running so many of the people who already have done a lot of research on how to make very fast responsiveness like the sixty fps constraint don't actually care about uh... initial render time a good example this is games right you every game in the world has a loading spinner that sometimes takes a very long time because they have decided it is because we're very important that we get fast interactivity we are willing to spend some large amount of time doing setup work on the web we simply cannot do that so we have a really hard constraint of how we make initial render time fast and also make uh... interactivity after that fast which is just and somewhat unexplored problem and the web forces us into and in general like a worse problem is that computer science used to have this memory versus speed trade off people might have heard of in like the sixties seventies whatever and at some point people decide oh there's like plenty of memory so you can always just do the work uh... whenever like up front but it turns out doing work up front also takes time right so it's not just a memory constraint which we have plenty of now we have gigabytes of memory it's also how long it takes to actually do that work so the web sort of changed how people are thinking about optimizations in general which means a lot of the ways people generally have thought about it so far are not directly applicable there's some questions that we need to resolve so that's it I would say that's the framing that I personally use for how what is the point of glimmer like trying to deal with this trade off uh... so basically that the web has a special problem which is we are required to boot up in very absurdly fast time like people's kind of like under one second you have to boot up and also you have to be sixty fps once you boot it like somehow like the I find it ironic that basically this is it's like the most beginner friendly environment in the world and it's like the hardest computer science problem in the world something is something has to give here and and like I think one thing that's interesting that you probably have noticed is that you can go really fast if you don't worry about updating right so if you're trying if you don't care about updating then you can do a very nice thing like either just use html or just run a very fat like a very fast series of operations and then that is the fastest so it's actually impossible like it's basically impossible any framework be it like inferno or vue.js or ember to beat vanilla jas because vanilla jas just doesn't care about updating and so what we're trying I think what everyone is trying to figure out like every framework is how can we have our cake and eat it too how can we get the initial render time down to a relatively low amount without sacrificing updating performance actually ember had a very extreme version of this problem because react when react came out they basically said we're gonna put we're gonna put updating performance to a side for a minute and some of the original talks about react that talked about ember basically ember has very fast updating time but unfortunately that updating time comes at a cost it's too expensive to render initially and we have actually come up with a system that has a better trade off and I agree actually the react system had a better trade off however we could because of the fact that we already have a lot of users with big app we actually couldn't regress on updating performance so we have to figure out how to create a system that was much faster initial render but also roughly the same speed at updating and that just made it hard like made the problem very hard and forced us into pretty creative problem-solving mode when we worked on glimmer so last year we had this we talked about glimmer and we said like we are getting like 1.5 to 2x performance speed boosts in component heavy scenarios we said last year I think that particular benchmark was actually very focused on component heavy scenarios real apps of course are a mix the good news is that when we actually landed glimmer we got roughly that we got somewhere between 1.5 and 2x on like the whole app people's whole apps and that's actually pretty cool I think like it's hard to ever find ways to make things twice as fast that without compatibility issues and we actually got both speed and size so like Robin Ward here works on Discord says I can't think of a release of a library of framework that reduced my app size and significantly improved performance ember 2.10 is super rare so and all these tweets are basically saying that honestly I was actually pretty scared because you can never know when you ship something and what the impact is but like uniformly people upgraded to that 10 and got very significant boost so the fact that we did that and was compatible is pretty pretty good and again I what I would say is we were basically forced into doing this because of the fact that we already have very good updating performance in the beginning and I want to talk a little bit about the architecture before handing it off to Tom to talk about fun stuff so there's a few wins like now that we know that glimmer is faster we can talk a little more I can talk more confidently about what parts of the architecture make it faster and smaller so first of all the way ember used to work is that we would compile templates to javascript which can be large some frameworks have very large output we had medium-sized but still pretty large output and one of the big changes that we made in glimmer was that we have a wire format that's intentionally designed to be compact so the wire format bait tries to do as much work as possible in the pre-compilation phase it is importantly not executable javascript which means that all your templates do not have to run in a like the vm doesn't have to run it's just the way we get them is just on that part which is much faster than executing javascript and also does not introduce like laziness considerations other things that cause slowness we also really wanted to we want to use this to reduce in browser work right we want to take as much as possible anything that we know ahead of time like this is a local variable or whatever and move it into the wire format and in general one thing that has been true about glimmer the whole time is that we want to take advantage of the declarative nature of our templating syntax right templating syntax has always had the the cost of not allowing you to just put random javascript expressions in there but has had the benefit of therefore being very upgradable to different architecture so the more we could take advantage of things that are latent in the in the wire in the syntax the better we can do at performance so uh... so that's why reformat that basically is just how people are like i my app is twice as like my whole app bundle is twice as that's how we did that there's another pretty major optimization that we do that allows us to beat other other rendering engines and that's the static content optimization we talked about last year i just want to show it we're running out of time but so here's a template that has a div and a span of some dynamic content in it that's the wire format and what actually happens in practices that we compile to uh... what is a by-code and i'm just using assembly notation here for convenience but there's no you can't write this anywhere there's no assembler compiler but it looks like roughly like this we basically take the template and we compile it into a series of small bike small opcodes and the important thing here is that the append pass you can see has like an open to open calls to close calls whatever and the updating pass is not the updating pass has a single revalidate of that curly uh... this is actually more or less this is a textual representation of more or less how it actually works someone asked me on twitter is it an analogy or is it how it is actually a by-code vm it is actually a by-code vm and the important thing is there's only one opcode out of the set on top that has any possibility of updating right so an open div cannot technically like by definition cannot be updated because it's like open a div there's no dynamic thing in there so there's nothing to update whereas the call thing technically one of the parameters the call could change so you have to do some work to update it so we have a good system that allows us to both rationalize what we're doing in terms of a by-code vm and then also extract from the initial renderer just a small amount of things that we have to do to update um i want to talk about performance because i've been talking about a lot without saying anything and i just want to briefly show some benchmarks but i want to mega caveat them perhaps more than you may have usually had caveats benchmarks are not just sometimes uh... obtuse or not giving you good information sometimes they're actively misleading and i think in practice they are usually actively misleading for various reasons this is a really good blog post by ben and dick mirror on the v-a team about how they basically spent multiple years working on optimizations that made their benchmarks faster that made the web slower like legitimately slower is like made ember slower by several times allow jsc to outperform them by sometimes like five x because they were chasing the wrong benchmarks so it's not just that like benchmarks might be not telling you a lot sometimes they are actually sending you down usually they're sending you down bad pass so i don't actually like the benchmarks that people use for web performance framework performance however that is what people use to figure out if you're fast so i have decided to run them for glimmer but please do not take away anything specific out of these benchmarks because i do not want to have to optimize for these particular benchmarks because they are not realistic so here is like initial render this is actually the case so there i said micro benchmark here because these benchmarks are basically they're rendering one thing they're rendering like a piece of dynamic content with no html so in the real world of course you have html because you have css so you need to make your html do something in the micro benchmarks that people test that you have seen online usually there's like one piece of dynamic content that's being rendered and that's fine but it's not it's not even remotely a real-world scenario so our initial render is a little like in the ballpark of the fast rendering engines it's a little slower our updating side is just always like reliably faster than our competitors on the glimmer vm just because of the static optimization it's like no matter what it's always faster basically and we we updated the benchmark that you probably have seen online that we're doing here with more realistic content which is basically just like take some bootstrap html that is needed to generate an icon and put it into the content because that probably needs to exist in people's relapse and if you put some content into the html and rerun the benchmarks you will find that the results are quite different we inferno is still very fast but we're still like quite worst now we're like very competitive and we're still in the right in the same ballpark right i think updating is probably the most like more interesting which is that when you start adding static content as you can understand why and based on my previous slides when you start adding static content we end up doing really well so in real apps you just end up with a lot of content that is not happened to be bound for some reason and glimmer is just glimmer is extremely good at that because we do exactly zero work on the updating pass for those that piece of content and so in the real world those that content exists and we end up beating even the most optimized react um react worker likes because of the fact that they end up having to do some work for the static content even if it's even if they managed to get that work to be relatively cheap they have to do some work so basically we do we're doing very well now that we're now that we have a thing that is running real content and is shipped we can look at how our vm performances and understand it um sorry so this is basically just a benchmark we did last year i just figured i would show it again it's basically uh the point of this benchmark for people who weren't here last year is every box is a component in this benchmark so our old system was bad at rendering components so if you added a lot of components it made things slow and now we take like components have to be fast as a hard constraint so there's a lot of them on this demo you actually have to scroll to see all the things that are on here so it's fast um so in general the TLDR is what we're trying to accomplish is to get into the sweet spot of initial render and updating performance so that we can uh continue to have very good updating without you having to think a lot about things like should component update but also get initial render fast so one last thing before uh fun stuff um so components are probably still an area where we could do better and so here's an example of a component that's in the glimmer vm is this is what a component looks like and this is what the wire format looks like and here is what the assembler looks like right now for that component and if you look at this you'll see that there's actually a number of things in the in the component assembler that basically are ember semantics so things like um you actually have a component class and it has some properties on it is actually a semantic that might not always be needed or um maybe in this case there are no blocks so why are we pushing them on to the stack or um things like parent view and child views might not always be needed so why are we supporting them so there's a lot of we have made these operations very cheap but there's a lot of things that intrinsically are not needed to make uh the component model and glimmer work and so um there's a thing that we have been working on in the architecture which is basically to allow you to remove those op codes um and godfrees rfc is actually about this godfrees rfc is about allowing people who are not build it like allow things that are not the ember components to still exist in ember um i know crystal um allow things that are not an ember to expressly opt out of features that they don't need to eliminate some of the op codes thank you yhuda so i don't know if you all know this but the way that yhuda and i get ready for keynotes is we just put old steve jobs videos on loop to a combo of chariots of fire eye the tiger which you can probably tell so when when steve jobs came back to apple in like 1998 after they purchased next apple was in a very bad place and uh as a mac user at the time so we're max and um steve jobs gave this talk that i thought was really good where he took maslow's hierarchy of needs and adapted it to the apple hierarchy of skepticism because you remember at the time every article in the press whether it was the tech press or the general press was every single one he's the word beleaguered i don't know if you guys remember that but there was a point where every article about apple is how beleaguered they were and so steve jobs gave this talk and he said you know i used to get really frustrated that every time we would solve one of these problems about the mac or about apple as a company it seemed like they were just moving the goalpost not there's another thing that they had to overcome some other objection he said i i used to get really frustrated by this says but now i actually appreciate it now i understand that when the objection changes it means that i have convinced them that the past thing has been fixed right so actually it means you're succeeding it actually means you're succeeding um and so i would like to introduce you to the ember hierarchy of skepticism um so if we start at the bottom right there were all these reasons people had for not wanting to use ember the first one was like the bill tooling was really bad didn't come with any bill tooling was hard to use we got dinged for not having any documentation basically you could have showed you the example that was like mega outdated and that was in 110 bind adder and metamorph just bloating up the dom and so these are all things that we have heard we've got that feedback and that we've convinced people that these are no longer problems but there are some that still remain so for example one thing that people complain a lot about when they look at an ember app is it it doesn't look like javascript it looks like this weird java thing with our custom class system right and so uh matthew bill and uh tom i apologize tom i forgot your last name um just because your first name is so good that uh so it's who i'm created have as probably many of you know every year do this community survey and we get some really fantastic feedback people are sometimes brutally honest but it really helps keep us honest and so people say largely is that they really wish the ember could integrate better with the rest of the module ecosystem um they don't like the fact that ember is this monolithic build they don't like the fact that it feels like you're leaving javascript and going into this foreign environment um and of course we oftentimes get dinged on size and speed so so on the other hand like people are usual like those were some cherry picked most negative people but there's most of the feedback is generally positive and people say that they feel very productive using ember or they feel like ember uh they feel like they will say positive things about ember cli right so there's right most people have a lot of things that they like about ember they opinionate nature convention of a configuration but there is definitely even people this example even someone who was generally happy has some of the same concerns that some of our biggest detractors have so i am really excited to share with you all something that we've been working really hard on uh which is glimmer and i think if you take that hierarchy of skepticism that people have about ember of all the reason they say that they don't want to use ember i think we knock out almost all of them so the first thing people say is they don't like you guys you you've all dealt with this tag name attribute bindings you all you want is a component like that's an input field and you have to write all of this javascript with this weird syntax that you have to learn just to have an input field an input tag with some attributes right this is not unfortunately me trolling us it's the reality yes as i'm sure many people know so in glimmer you could express everything about the root element of a component all in your template it's like an outer html instead of an inner html so this is an this is like another sorry keep going so the the point here is that you can bind dynamic content from your component to your template without having to learn these esoteric invocations of the and i and like the components in taxes is just javascript right that's like you can see so of course you can get there are a lot of cases now where you can get away with not having any javascript class at all because you just have some html in the outer html and all you were doing was writing attribute bindings but there are still some cases where you need a component a lot of cases and the syntax for that is a javascript class esx class and of course one thing that people ask us all the time i want to be able to use typescript with ember well with glimmer it's written in typescript so of course it's super easy to use and you get awesome autocomplete intelligence inline code documentation inline documentation the whole bit and of course computer properties people always say why can't i just use accessors well now you can and why do i have to put dot computed on the end of all of my properties well you don't have to do that dot computed anymore you don't have to have these weird ember syntaxes now you can just use decorators which is a stage two feature in tc39 and these of course pair very well together so you get really nice functionality so you can annotate your fields and get type checking as you're typing your code which is really really nice actions in your template are no longer some weird ember thing the action helper just takes those functions and binds them and you can install it as a click on on click helper for example on site of an element and just it's just a regular function with arguments that get curried and probably the biggest one people hate get and set with with the javascript accessors with glimmer you don't need this anymore so how many of you saw that article that was going around about the size of the output from hello world apps from different cli tools i'm glad not many people saw it so this test was i go to the website for this for this framework or this library i get the recommended cli tool i install it i do a production build i check the size so you can see that ember is not what we call in the same ballpark as the others it's significantly larger and this file size unfortunately makes many people consider ember to be disqualified and i think what's really exciting to me is that the output of a hello world app from glimmer is just about 30k so that is less even than view and the only other library beating us right now is pre-act and i think they can have that so um that's me uh i uh i just want to share with you a video that um ryan and sam from ember map have created and this is just going to show you the what the experience of writing a glimmer app is like and i think you're really going to enjoy it today i want to show you glimmer js glimmer is a new javascript component library that helps you build rich dynamic user interfaces for the web extracted from ember's battle tested rendering layer glimmer is fast enough to be used on the mobile web so simple that you can learn the basics in just a few minutes let me show you how it works to get started we'll first install ember cli glimmer uses ember cli to help you get up and running without any setup or configuration we can create our first glimmer app by using ember new with the glimmer blueprint ember cli has generated an app directory for us if we open it up we'll find that our new project has been scaffolded and is ready to go glimmer components are made up of templates and javascript files let's start by making our first component called weather tracker glimmer templates are built on html so let's paste in some existing code we actually now have our first working glimmer component let's try it out by opening the app template adding our weather tracker component and starting the ember server if we open the app in a browser we can see that our weather tracker component is being rendered glimmer makes it easy to build data-driven components our weather tracker currently has a temperature hard coded in its template let's replace that with some javascript that they'll open our component file and define an object called weather that has a temperature property we can now display this data in our template using a familiar handlebars light syntax and just like that our components output is being rendered from local data our component would be a lot more useful if it was displaying current live data from the server so let's implement that now to start we'll use the tracked decorator to tell glimmer the data within our weather object can now change we've just made our component reactive it will now intelligently re-render whenever the weather property changes next let's write a function that requests the latest data from an api because glimmer comes with typescript out of the box we can write this async risk function using async and await we'll start by writing an async function called load weather we'll request data from the server and then set our weather property to the resulting JSON object finally we'll kick off this function in our components constructor so it runs whenever our component is used and we can see that our component is now rendering data from the server let's update our load weather function to poll every two seconds our data is now changing and glimmer is keeping our templates in sync now you may have heard that glimmer is one of the fastest javascript rendering engines and while our weather tracker is pretty simple glimmer maintains that performance even under significantly more load but how does that work first glimmer compiles your templates down into a compact series of instructions known as bytecode besides being small in size these instructions are extremely efficient since all of your tracked variables are known ahead of time glimmer is able to avoid unnecessary re-renders of your application without any optimization effort from you when your app boots up on the client glimmer's virtual machine reads in your template bytecode and produces a streamlined program to render your data-driven application this novel approach is what makes glimmer one of the fastest javascript rendering engines while also being one of the smallest glimmer embraces all of the patterns of composition that you've come to expect from a modern component library for example we can pass arguments into components right now our weather tracker only shows the weather for new let's update it to take in a zip code as an argument first we'll add a second weather tracker to our application and we'll pass in a zip code for san francisco glimmer uses the at symbol to distinguish between javascript data that we pass to our components in normal html attributes like class now in our component we can use that new zip argument in our load weather function and now we can see the weather for san francisco shows up in this video we've touched on just some of the features that glimmer gives you for building rich javascript components and when you're ready to ship mrcli provides an easy way to distribute those components to existing web applications the ember build command gives you a script that you can drop into any javascript or server rendered web app that script exports your glimmer components as web components meaning you can use them in your apps just like you would any other native html element glimmer's rendering engine and powerful composition story bundled with cutting edge features like pipe script support esx classes and an opinionated file system make it a joy to work with we took the same technology that powers ember and made it simple small and lightning fast and i'm so excited to finally get to share it with you so go try it out and build something awesome and next i just wanted to play this candy pickle chili video for you which is the sequel okay we're like mega over time here so i think first of all that that was not a mock-up that exists in the world you should use it you can go to glimmerjs.com and install it now yeah but we should probably talk about how this connects to ember since this is ember conf and also probably you were not want it you would not want us to announce that we are abandoning ember which we are not so you may be curious to hear how it is connected um so first of all this is the the component api we want for ember um so i talked a lot before about the way that were the fact that we're modeling more of how ember works so that we can do experimentation outside of ember this is an example of that right we we really want ember's primitives to be able to allow the glimmer api library to work on top of ember we ultimately want something like the glimmer api to be the ember api and we need to get there and so godfrey's rfc number 213 is basically the primitive that we need to allow people to allow you to write glimmer the glimmer add-ons the glimmer api as an add-on and that's that's the plan for how you can use the component api in um an ember soon um there's also uh you saw in the video an improved directory structure if people have been following along uh you probably know that there is the module unification uh feature um is basically the improved directory structure for ember it's uh it is a it has been a long project in a large process um glimmer is the first project that uses it natively um but there is already uh an add-on that you can install in ember now that uses the low-level resolver api to allow you to do a hybrid of the glimmer directory structure and the ember directory structure as i said before the tldr of that is that you can put components and helpers etc uh alongside the place where they belong co-located with where they belong um the only option that you'll need is to change the app directory to the source directory and install the add-on um there's a bigger project of like uh how we migrate people so there's a migrator project that you can run to migrate your um app but we also expect that people will end up having both the app directory and the source directory for some period of time while they migrate um but that's also something that is already happening in ember um probably if you've been following along you recognize some of these details the the points that module unification links right now the ember and the glimmer worlds so our goal is that very soon you would be able to take your components from a glimmer app drag and drop them into an ember app and it would just work and would get the same performance that you would expect from the glimmer app um typescript is also a thing that is easier for us to do in glimmer because of the fact that we of course wrote it in typescript so it's very easy for typescript apps to consume typescript libraries um there's another thing we have been working on with the typescript team for the past uh probably year which is to enhance the typescript language enough to support some of the more dynamic features in ember and they announced in both 2.2 and 2.3 some new features and the cool thing about this so this is an example that we worked on together with um the project manager at typescript and the cool thing about this demo is that it's using ember.object.extend like it's using a subclass of ember.object.extend and it's using get and the get string literal is code completing right so basically typescript is quite powerful now and a lot of that power was in in order to allow us to support um typescript and ember uh it actually works with just javascript files I actually noticed this like inadvertently the other day I was I made a new ember app and went into it and typed const computed equals ember.computed and then type computed that lte and I got type signature and I was like how is that possible um the the way it's possible is that vs code now has automatic type acquisition that will download the type files for you which somebody else wrote and it gets the right thing so this demo here is using an updated version of that uh dts so you get some of the benefits like this code completion example um without you can see there are no types in this file there are no mandatory types in this file and it's it could just it could be just a js file and you still get a lot of the benefits but of course we want you to be able to use ts files also so um the the thing is we really like typescript I think in general we don't ever want to build features that mandate that you use typescript we never want to force anybody to use typescript um we never want to make it a core requirement of the semantics but we really do want using typescript to be a pleasant experience I think because a lot of us have come to really like it building glimmer and that is a this is what happens when you make slides on the web uh so the the idea basically so you glimmer is basically designed for um today if you want to use glimmer it's designed for building small mobile applications which were not a good fit for ember before I think nobody would claim otherwise and ember is still really what you used to build big ambitious applications as a cli tool it has a router it has add-ons things that services things that you might need if you're building a bigger application um but it's it's probably important that that you not have to constantly pick and choose between just using glimmer or just using whole ember there should be a spectrum in between um we don't currently have anything yet but the plan that we are really really web beautiful very gorgeous the plan that we have here is basically that we are going to repeat the process of extracting glimmer out from ember um and maybe rewrite slides.com in ember um no we we're going to repeat the process of extracting uh pieces of ember out like the router um like ember data um so that they're more rationalized as standalone components and the ultimate idea is that you can um npm install your way to ember right start from glimmer and then npm install your way up so that process of getting to that vision requires that we uh do that a piece at a time right we start with glimmer and then we say you know what's the next thing maybe the next we already did it for the di system the container system maybe the next thing is the router um there's various this is a community project so we will basically totally based on what ends up getting pulled from the community but there's more there's there's more work that can be done along these lines and I think ultimately starting with the thing that is 30k and adding things as needed up to ember is is good people have asked for tree shaking by the way and I think that's a like we like glimmer application does tree shaking with roll up out of the box but ultimately like human beings need to understand what they're opting into and not be reliant on extremely magic optimizations that could fail at any time so I think thinking about oh I actually need a router therefore I will add it to my project is a good thing to be able to do even if we were somehow able to magically make it optimized so um anyway the t the tldr is uh we the ultimate vision here is that ember is still like the end game for ember is it will be faster and more um generally more rationalized but it has the feature set that you expect today and glimmer is designed for small mobile apps and then if you as in between you opt into packages that were extracted from ember that's it thank you