 I have a tough act to follow. First of all, there's only one of me, but what I lack in count I make up for in volume, so it's fine. So hopefully, you guys know somewhat about who I am, but I'm a core team member. I have a very severe open source problem, like significantly severe, to the point where some co-workers saw that I didn't commit something for a day and were concerned and called to check in to make sure that I was OK. And I work at Twitch. And it's a really awesome team over there. We're building awesome features, and it's really great to see some of the things that Tommy who talked about some of the things we've been doing in Ember over the course of the last, I guess, two years since I've been working on it, really applied and ramped forward in like a pre-1.0 app all the way up to now we're on the latest LTS, and it's great. Before I get too far into it, I always like to bring up my family and have a slide for them. Like none of the things that I could do, I could do without them. They are like the foundation behind everything that I'm able to do. And I'm sure that y'all can also say similar about y'all's family. So I always like to make sure to make that a point. All right, so now the thing I'm going to talk about is a little bit different for me. So usually I'm up here giving talks about technical things and deep internal code slides and all this stuff. But I don't believe there are any slides with code on them. So we're going to work this out together. I also, I'm doing an experiment. So I sent my slide deck to one of the core team emeritus, Alex Machinier, last night. And he sent me back to my slide deck slightly modified. So I have not seen this slide deck. So we'll see what happens. It'll be great. It'll be great. Just hopefully we'll just hit next real fast if we see anything upsetting. So it'll be fine. So the thing I'm going to talk about is basically how can we move forward with all of the great pie in the sky things that Tom and Yehuda talked about, things that some of it we can use today. But it's a little bit of work, like Tom mentioned. And how do we, as a community, as a framework, how do we move from one place to another place? Basically, how do you chart a course from, essentially, where you are, the past, basically, through into the future where you want to go. And how that works for Ember, for your apps. And I'm going to show how you can actually do the same things that we do as framework authors inside your app. And it actually makes the same amount of sense. So let's just, like, brief look at some of the things we've done in Ember. So when I first started in Ember, it was just before 1.0. I barely knew any JavaScript. I grabbed Ember because it was the one that seemed the most sane at the time. Thankfully, I still agree with that assessment. But we had some, so to me, really confusing things going on in the apps that we built at the time. Things like container view, manually managing all your views, appending them and whatnot. Using context shifting in your templates. Matt Beal gave a great talk at last year's Ember camp about this exact thing, about how templates in modern Ember are like they actually have lexical scope. And it's actually more like real programming. And he explains it way better. Also a great aside about crisps and chips. So you got to watch it. And then this is the thing that really got me. So I came from the rail's land. And testing is really ingrained in the Ruby space. And when I started with Ember, obviously I love Ember. But really testing, really? I could not figure out how to get my Ember 1.0 app to be tested with anything other than just running Capybara and driving the browser manually. And that was really, really slow. And every time I had a new test, we had a significant slowdown in CI speed and all the stuff. These are just some of the places we've come from. So thankfully, Ember 2.0 let us drop some of the wacky things. We've killed views. We've killed the proxy and controllers, like object controller and ray controller. And the context shifting. So to me, the biggest thing that we removed was the context shifting. That was the most mind-bending thing looking at a template not knowing what curly, curly foo actually referenced in that context. That was super, super difficult to track. It's also one of the most complicated things to refactor away from. Because as you refactor your templates, you might want to extract two components. You might want to pull out and just invoke individual components in your each or something like that. And it becomes really complicated to know where this specific mustache invocation is actually referencing. What is this in the context? So that was a really huge thing in my mind that we were able to move away from. And then, so today's testing stories is actually pretty decent. You can Ember generate a component and you get a test and you can render a block, a handlebar snippet, and you can see what it looks like. And then you can assert on its output. I think that's great. That's light years beyond where I started with Ember. And in today, if you read Hacker News, which I actually don't suggest anyone do, if you do, you'll actually see Ember being represented as the thing that does testing right, which is like the world has been turned upside down from where we started. And I think that is amazing. And I think that sort of transition, those things are only possible because we have a process for plotting a course and moving things into the future. So we have, so what is next? Now we're still doing this, you don't stop. We've done things, we've moved from one place to another, and we still have a long way to go, right? So some of the things we're currently talking about, you've seen them in RFCs, but like project layout, how things look, the better testing harness, both of those are in RFCs. Performance, Tommy and you had talked a lot about that and a lot of the work that's going into Glimmer 2 and the object model stuff is all related to this. And then making Ember more modular, so you can start with smaller chunks and sort of ramp up as you go. So this is what we're doing. Hi boys, yeah, the future, yes, the future, yes. All right, so now let's talk about how do we do these things? How does this work for Ember and what do we actually do? So the first thing you've got to do is you have to identify what's going, like you have to look at your project, the Ember apps and find things that are wrong, find things that feel bad, find things that need improvement, right? So you've got to analyze what's been working for you, what's not been working for you, and that process actually itself is hard because you're so ingrained in doing the things and building the things that sometimes having that independent perspective of like, wait, this kind of is nuts, this kind of is not great, is sometimes hard to do. So this is the first step, like identifying things that need work and improvement. And then you've got to come up with a plan. The plan doesn't have to be specific about like steps and details, but you need to know, so now you've identified the things and you've got to plan what do you want the future to be. Now oftentimes what I find, well from my perspective, one of the things that I find that we do is we're more focused on what we want the future to look like and less focus about the steps between the two things other than to make sure that it's possible. So like it's a thing when I do add-ons or do independent open source development, like not Ember stuff, I oftentimes do like read me driven development, right? Like what do I want this API to, like before I written any code, how do I want to use this component? How do I want to use this library? And that's the kind of thing that you have to do, like what do we want it to be? Like we know that this is messed up, something is wrong, and we have an idea that something is going not well here, but you have to decide like how do you want it to work? Like you have to figure out the general idea of a plan forward. Then you need to communicate that. So in Ember, we have RFC process, we have a ton of folks giving talks, like Tommy and Huda, myself, all the core team, like we're out evangelizing for the future for the plans that we're making. And the RFC process allows us to communicate with our community, with the stakeholders, the people that actually care, and take their comments and take their feedback and actually roll it back into the plan and change things. We're also able to make sure that the path, the individual steps, like the way you teach a thing, the way a thing is interpreted and handled, all of that stuff can be fleshed out together, right? Like you guys have a way better idea of what it's like to be a new Ember user than I do, probably, right? You guys all interface and you have coworkers, you have people that you see all the time that are new folks to Ember. So this is a super important feedback cycle on the RFCs, on the planning things. So if we had done the original version of the module proposal that people pushed back on, if we had done that without actually asking for feedback from the community, we would have been way worse than where we are today. And I think this part is super important. And this is actually equally important in app stuff. So then we gotta implement. Oftentimes, this comes together with the RFC process. So I find myself spiking things to see is this feasible, especially for migration stuff, like is it possible to go to bridge the gap? Can you run things together? Like with the testing RFC, we have to make sure that all those grand ideas that I wrote that we can actually do them and that you can still run your current tests side by side. Rewriting all of your tests would be horrible. So things like that. So the implementation then informs the cycle and it lets you continue to improve the plan and the RFC or the communication aspect, like in a nice cycle. And then you continue, you repeat. All right, Zoe solitaire, nice. So then you continue, you repeat. You basically start over. Like you then continue to identify more things and repeat the cycle. So we have a whole slew of outstanding RFCs, things that we're working on in the middle of, progressing forward and this is really good. This is the same thing that I think that most people should be doing. So you wanna give a great talk back in 2011, I think, called Framework Thinking. And this is the sort of stuff you're talking about. Basically thinking like a framework developer as opposed to just an app developer, quote unquote. And so when I proposed to give the talk, like the thing that I wanted to show was these things, while they may be great for the core team, how does this help you? What does this have to do with you and your apps? Oh, all right, there we go. So how do you take these things from, from like me up here talking about us doing things in framework and how do you apply them to your app? So first of all, you have to identify things. So in your app, like you've got patterns. You've got things that are painful. You've got things that don't work well. Eric's gonna come up and talk about theming. That's a really good example of something that most people do really horribly. And you don't know you've done it bad until you're like miles deep in a pile of crap. And that's bad, right? So another thing is you end up with these components that have these ever-growing signatures of like, oh, let's just tack on a 12th param. Or like, and it gets really hard and gnarly to track and figure out what's going on. So this is the kind of thing, like in Twitch's app, we have a number of things where from views, from like having hundreds of views to things where you've got this repeated boilerplate code in the templates that you could have refracted to components. Those are the kinds of things that we're talking about. Identifying those things is exactly the same as you do in a framework, right? Like it's no different. Like you're literally just looking at your app at the things you deal with on a daily basis and deciding like what things kind of smell fishy. And then you make a plan. You have to decide what do we want this to look like. It's exactly the same problem. You know, you've gotta figure out where's the future, where we want it to go. Like you're not gonna be able to go there in one step but you need to know where you want to go or you can't get anywhere, right? And sometimes lateral movements, refactoring from a view to just being like maybe a wrapper component or refactoring from like creating a new component to start replacing usages of an older legacy one, things like that. Those are the small steps while they may seem somewhat lateral at the time are ultimately the things that let you step forward and move on. So part of the plan just like in framework development, part of the plan is figuring out how to teach your coworkers. How do you show the way you use these components, the way you use the tools to other developers. Part of the plan is deciding how do you deal with backwards compatibility. It's figuring out what do we do about like maybe you've decided a component that's used in like 20 or 30 places now needs to be refactored to either do less things or change boilerplate or accept the block where before it was blockless, things like that. How do you go from one to the other and what's that path? How do you do it without breaking backwards compatibility? In this context it's like migrating one invocation at a time but it's the same problem, right? It's the same thing you do in frameworks. So this plan, this planning stages is essentially figuring out how do you make those steps? How do you make those lateral movements or small improvements over time? And then you communicate. So in app development this is obviously different than RFCs for us but it's exactly the same problem. You have to communicate with the stakeholders, with whoever's in charge of product, your other coworkers, you have to work with your team and the folks that the designers or whomever's working with you on the app, right? So it's exactly the same problem. You have to know how you're interfacing, you have to discuss this and make sure that you've accounted for all the things in your plan. And then you have implement. And when you implement it it's going to be similar to when we implement and influence the plan in framework development. So as you go forward and you implement, like say you're taking that theoretical case where you have a component that's used in a bunch of sites and you're refactoring it to a new component, you have to decide, well, am I just going to copy all the code into a new thing so I can start and just change one invocation at a time to the new syntax? Are you going to try to make the change backwards compatible and slowly just refactor the invocations? Those are the things you have to have informed by the implementation. Sometimes it's actually not possible to change the invocation sites and use the same component. You need like to duplicate so you can move forward. And it feels like a small step at the very least laterally possibly backwards to actually now have two things that have the same code in it or the same purpose. But the point is over time you're going to migrate off of one and towards another. And I think that that's very similar to what we do in Ember, right? Like we have the same problems. We have to migrate people off of some APIs to other APIs and oftentimes we have both of them in parallel for a long time with deprecations and like guided back forward. And this is exactly the same thing you would do in your app. And then you repeat, just like this guy in the background here. So you continue the cycle, you continue forward, you continue iterating and it never stops, right? You're always, there's always something that you can do better. There's always something moving forward. There's always something in both the, like the general ecosystem space that you're going to want to take advantage of and you're going to want to always continue to iterate. So I actually think that the, why are they so small now? So I actually think that it's exactly the same thing. And I hope that you guys can start thinking about thinking about the same problems that you deal with in your app, the same migrations as we do in framework land. Thank you.