 All right, y'all, I'm gonna go ahead and get started. So there's a few warnings slash caveats before I get started. First one is, as you saw earlier, I was heckling Nathan heavily. I expect equal heckling in return. The second one is that I gave my slide deck to a friend of mine, Alex Machnier, before presenting. And, you know, we're not quite sure what's gonna come up. So hopefully it's all good. It's all in good fun, hopefully. So we'll see what happens. Slightly nervous about that, but it should be good. So the idea here is, I'm gonna talk a little bit about how we take Ember, how we take the framework and conceptual stuff from where we started, where we're coming from, and into the future. So, but first, a little bit about myself. I'm an Ember core team member. I have a severe open source problem, although I will say I'm recovering slightly. I have some blank spots on my timeline now. So I'm very proud of that. I do not suggest anyone go for crazy streaks. Interestingly, they took the total number of days in a streak down just a day before I hit 1,000. Just saying, I may have broken the GitHub UI so they had to change it. And I work here at Twitch. It's really awesome to work with so many smart people. I've never quite been on a team with this caliber of folks before. If you're interested in a job, we are definitely looking for good people. Any talk that I give, if you've seen them before, I always talk a little bit about my family. These are my boys. There are now, they are seven and eight. And I just couldn't do any of the stuff that I do without the support of my family and them. And so I always like to throw them up on a slide. So I'm glad he did not add any mustaches or anything to the kids. All right, so the first thing is like, so how do we keep moving forward? How does the framework, like Ember has come from some really bad times. I started with Ember just before the 1.0. I'm sure many of you have been involved longer than me. That's great. We can trade war stories later. There's plenty of beer. So at Ember 1.0, we had all sorts of things, all sorts of concepts that later turned out to be really horrible ideas, like really, really bad things. And I'm sure some of you are still dealing with some of these things. So we had like views, container view where you can manually create view instances and like append them completely on your own where you'd have the view helper, which could potentially change the context or whatever. And then proxy and controllers. So your templates turned into essentially a nomad's land of not knowing what Curly Curly Foo actually points to. Is this a model property? Is this a, what is this a computer property on my controller? What is this thing? We had context shifting, making all of that even like 10 times worse. So with context shifting, like you'd have in each and then the block for the each would be like 50 lines long, of course, filling your editor. And you have no idea where Curly Curly Foo is coming from. Is it the iteration? Is it the item you're iterating over? Is it your item controller? Is it a computer property on the actual controller? Is it a route model property? Like what the hell is happening? Literally nobody knows. So yeah. And then testing seriously. Who did testing? Anybody in 1.0? Like really? Is that a thing? I tried really, really hard to test the first 1.0 app that I wrote and failed miserably. Like really bad, like it was horrible. And I got really sad. Okay. So now today we've come some place, right? We've gotten rid of some of the horrible baggage. Testing actually kind of works mostly, right? There's things that are that need to be better. There's things that we're trying to progress on. But you can do it, right? Like most people today, like if you read Hacker News, I feel like I'm in like the Twilight Zone because like Hacker News is like, ah, if you want to test, you should use Ember. I'm like, what? So this is great. So you have a bunch of different kinds of testing. We killed this context shift, I think, because like bananas and proxy controllers are basically dead. There were still some legacy add-ons you could use for a while to help you transition. But the idea is basically, if you look at a template, you know where things are coming from. You know, if you see Foo in a thing and not model that Foo, you know it's coming from the controller or the component context, whichever the context is at that place. The template land became much closer to basically a lexical scope, right? Like things that we can actually reason about and not troll ourselves. So this is great. And now the future, right? So, so, so, you know, where we're going. Like basically we're gonna have, you know, we've got an RFC open for the new project layout, which is the module RFC. It proposes a brand new way of laying out your project as well as additional packages or engines or add-ons and repo add-ons and stuff. And it learns from a lot of the things in the past. We've got the same sort of process in RFC coming from the testing perspective to make, to like sort of bridge the gap between acceptance testing and integration testing, unit testing and making them all have a consistent API. And we're, we've been focusing like a lot on the performance, the runtime performance, the individual rendering performance, the re-render performance, all that kind of stuff. And that's gonna continue to move forward and to make it more modular. As Nathan mentioned, like where you can bring Amber is an add-on. You can have individual parts that are more swappable. You can augment the core framework with additional things or remove things that you don't need, right? Like you may not need some, like, because Amber follows Amber, you may, we ship things that most apps probably don't use. Like things that were possible in 2.x that we have to keep around until 3.0, but you may not use them. So things like that where you'll be able to strip those sort of features out of your app or out of the build of Amber that you're using and make your code even leaner, tree shaking, all that kind of jazz. So that's where we're going. So, okay. Hey, boys. So how the heck do we do that, right? Like that's the thing that we all care about, right? Like that's the thing that's tricky. We have to know both where we've come from, what we have today, what we have to support, what the APIs are, and how do we get, oh well, and then where we want to go, like what's wrong with it? We have to identify those things and then we need to figure out like, what's the future? What do things look like? So how do we do that? So the first thing you have to do is troll Yehuda a little bit and you've got to figure out what's wrong. What's wrong with the system? What do you have in the system that is problematic or doesn't work? It was really easy in number one at .x. When we got to like one five, one six, it was really easy to sit down and look at those things and say, wow, this is really messed up. And now similarly, we're like at two eight now or two eights and beta now, it's also easy to see things in two X that we wish that we could move forward on, we could get rid of or migrate forward on. So the first step is like identifying what's wrong. It's identifying and figuring out what are the things that cause pain, what are the things that are preventing you from moving forward? The next step is probably obviously to plan. So I like to call this like read me driven development, like essentially figure out forget about the baggage of the past and figure out what do you want it to look like? What do you actually want the ideal API to be? When we sat down and we looked at like contact shifting or template scoping and stuff like that, we actually had to figure out what do we actually want it to do and then how do we figure out how to make it work? Obviously being compatible, being Denver compatible is immensely important for us, but it's also really important that we have a path forward and we know where that forward place is, right? So the second step is to plan and figure that out. So then with Amber, especially recently, we've been really trying to push forward the RFC process and communicate and talk to users, figure out what people's problems are and make sure that we're on the same page from the core team perspective of what we think is wrong and what cause people pain and communicate with users, right? So we have RFCs open, I mentioned earlier, we have RFCs open for the module unification stuff, for testing, to line testing up with all the three different types of testing in one mechanism and there'll be even more things like with angle bracket components will come down and there'll be another RFC for that, hopefully pretty soon. So it's really important to communicate with the community in our case to figure out, hey, this is what we see as problems, we're all working in perhaps, we're all sort of feeling the same pain and we're banding together to sort of figure out where to go and what we can do and what we can make better. So this communication is super important and frankly, if you look at the threads on some of the RFCs, you can really see how the conversations with the community have directly shaped the direction that we've gone. Like a whole bunch of different things between module unification where we, we had an initial RFC that we proposed and ultimately people just flipped out, right? It was horrible essentially and then we did like 50 or 60 iterations, like there was a gist that we were putting together before we circulated it with a second version of it with users and it was like 60 different revisions of that gist, like where we came up with things to the point where we had considered and discarded so many things that we didn't actually remember why we discarded all of them anymore. Yeah. So the next thing is implement, right? So we have to figure out, so now we know where we're going, now we have to actually implement it, figure out how to make it happen and then make it happen and figure out then how to make it backwards compatible, how to make it work with people's apps today, hopefully ship it outside of Ember as a separate piece from Core so that people can actually use it and test it and give feedback on it before we bake it in as part of the framework. Similar to what Nathan is talking about with Adam, right? Like Route Recognizer would be great if you could pull this in. Now right now, unfortunately, that is slightly trolling because like you're actually shipping two versions of Route Recognizer to the users like to your runtime because there's no way Ember right now ships is like one blob like ember.min.js or whatever. So we need to get better at that, right? That's part of the process, right? But at least now we can iterate, we can actually have a way for those enterprising souls to actually test these things and figure out how to move forward, how to make it better. And then bring that back for the whole group and make everybody have access to the good times basically. And then repeat. Do it over again, start all over. Realize that all the things you thought were perfect in the new design are also horrible. And start fresh. So that's fine for the core team. It's fine for us to do that instead of sitting in our little ivory tower and say, hey, this is where Ember is going, this is what we're gonna do. The thing that I'm here to tell you is, thank you. Oh. All right. All right. Thank you, Alex. The thing I'm here to tell you is that it's actually the same thing you're supposed to do in your apps. It's exactly the same problem that you have in app development today. It's the same problem that Casey told us about with Engines, the same problem Nathan's talking about with LinkedIn's Routt Recognizer taking a second. It's the same problem that I'm gonna tell you about. It's literally the same thing. So in your app, you have problems, right? Like there's things in your app that suck. I guarantee you, I promise. Ask somebody, they'll tell you. There's things that are bad, right? There's things that you should make better or that you could make better, right? Your app, parts of your app are a framework. They are building blocks for building your app, right? So it's literally the same thing. Like you need to identify the things in your app that do and don't work and just know, hey, these are pain points. These are problems. We should deal with these. You should make a plan. It's exactly the same thing. Like literally you should say, hey, using this component is either costly or painful or troublesome or very trolling, right? Like the API of this component, invoking this component, maybe it's a form or a text field or something. It's really, it's horrible, right? So you should make a plan. What do we want to do? Like sometimes it's fix it. Sometimes it's replace it. Sometimes it's like delete it from the code base and never think about it again, right? But you have to make a plan. You have to figure stuff out. And then you have to use bananas. And so then you have to communicate. You have to communicate with your project managers. You have to communicate with your coworkers. You have to figure out, like you have to say, hey, this is the plan. This is where I'm going. This is where I think we need to go. And you have to get buy in. You have to convince your coworkers or your project managers or the stakeholders or whomever you're working for or with that, hey, this is where we want to go. This is important. This is more than just shipping in a feature. If we keep shipping features, eventually, and don't fix these things, eventually you're going to be the point where you can't ship features anymore. So this communication is key. You've got to get their buy in. You've got to convince people that you need to be able to move forward. And then you're going to implement. Usually in App Land, I say it's easier. It's actually not easier. It's somewhat easier because you actually know exactly the API that's in use. Whereas from a framework perspective, sadly, Ember has a lot of APIs, most of which I wish didn't exist. And we have to support all of them because that's what we are guaranteeing. That's important for us to say, hey, you can use these things. This is Ember. But from your app, you may have a specific component. And this component has problems. When you go and redesign a component, you can easily see all the places it's invoked. It's not tricky. It's not complicated. You know exactly where it's used. And you can make sure that you replace it. So you can implement this. Now, the implementation may be fixing it. It may be replacing it. It could be essentially deprecating it. And in one technique, for example, that I've used here is when you're going to build a new component, build a new one for the next use case, the next usage of a given shared component, and then have a test that errors if you use it more than x times. So that way, you just don't get worse. You can make sure that you are only invoking the component at the same number of times. And slowly over time, it goes down. And you know that it's getting better. And you can do the same sort of things that we do. We do an Ember. You can deprecate. You can have things that give compile time warnings. You can use ESLint features to do warnings on given method calls, things like that. It's the same sort of things that we do in Ember. And then you like the hamster in the background. So I don't think that's a tomster in the background. I think that's a hamster running on the wheel. You keep going. Like, you don't stop. You keep running. There's always things that you're going to keep doing and try to make better. So basically what I'm telling you is that app development is not that different than framework development. And the problem space is roughly the same. You just don't know it yet. That's it. So I have time for some questions, I think. There's going to grab a microphone. Wait till you get the mic before you ask questions. Hey, Robert, great talk. So let's talk about how we convince our bosses to go through an RFC process or some kind of communication where we get to actually push back on a new feature. Yeah, so there's a few things, right? Like, first of all, if you work for someone that literally doesn't care about your input, why are you there? That's the first thing. The second thing is you basically have to have a report. You have to have a way to communicate. Usually there is a process where you can maybe add things to a backlog or parking lot or whatever, where you can flag things, hey, this is messed up. We should deal with this at some point. Now, sometimes you'll flag those things and they will literally never come up to work on and they'll never move forward. But other times, more often than not, like you bring it up and say, no, this is getting really important. Like, hey, this feature is not tested or these things are not testable or things like that, right? So I can't sit here and tell you how to talk to your boss, but I can tell you that talking to your boss is really important, right? And the stakeholders, the project managers, whomever it is that is in charge of deciding the future of the product, those people generally, if they're actually good at their jobs, generally care what your input is, right? They generally want to make things better because they want to keep iterating. They want to keep adding features, right? And if they want to keep adding features, they need to make it easier to add the features. So I don't, I think I'd basically just like walked around your question. Thanks, everybody. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.