 All right, I think our live stream is up and running. So, hello everyone, and welcome to the Ember Framework Core Team AMA. Ask me anything live stream event. My name is Jen Weber, and today I'm here with some of the Ember Framework Core Team members and our guest facilitator, Carl Becker. Ember is a JavaScript framework that provides everything you need to build modern web applications. The Ember project is guided by a group of developers from different companies known as core team members. Together with the community, the core team members work to ensure the project's long-term success, stability for users, excellent developer experience, framework accessibility, and more. There are multiple core teams, and today we're speaking with some of the members who focus on the framework itself. To learn more about why Ember is a good choice for your own web app projects, you can visit yember.com. With that, I'd like to pass things over to Carl. Thanks, Jen. Hi everyone, my name is Carl Becker. I'm the technical co-founder of a small company called Third Iron. We've used Ember at Third Iron for over six years to power our two web products, Browseen and Libkey. These Ember apps are used by researchers to stay up to date with peer-reviewed journal articles at over 1,200 libraries, ranging from universities to corporations, hospitals and government agencies. Ember has been instrumental in our small company's success, which has allowed us to grow our software development team like our company and many other companies are growing now. And I think it's safe to say Ember has helped all the careers of the framework team members who are joining us today. For everyone watching, we hope Ember is helping your career in life too. I'm excited to host this question and answer session with the Ember frameworks team. Today, we are going to have some questions that readers of the Ember times have submitted. And we also encourage anyone watching the live stream that posts their own questions here on YouTube. We'll spend some time answering those questions sent ahead of time and also try to get a few of the live questions too. So let's go ahead, go around the room and have all of our framework team members introduce themselves. How about each person shares one of your favorite things you've worked on in the past year and then popcorn to someone else? Let's say popcorn Melanie. I have a meeting right now. I didn't realize that. And you are unmuted. All right. Hi, I'm Melanie Sumner and my focus on the framework is accessibility. And the thing I've most recently worked on is pairing with Yehuda to make unique ID, a feature that we can implement in template only components. So I'm really excited about that. I'm gonna popcorn over to Ed. Hi, I'm Ed Faulkner. I've worked on a lot of different things in Ember. Most lately though, I'm focused on the build system and our next generation build tooling around Embrider. That's what I've been working on. Most recently I've ported some more add-ons like Ember page title to the new V2 add-on format. And popcorn to Robert. Hey, I am Robert. I've been mostly working lately with Ed on the Embrider side of things, trying to push our LinkedIn's Embrider adoption forward and get more apps deployed to production and sort of smooth rough edges so that we can begin making it more feasible to have it be default out of the box experience. I think we're getting close but I'm sure we'll talk about that more later. I will kick it over to Katie. Hi, I'm Katie. I most recently have been working on support for V2 add-ons in Ember Observer and generally you'll find me doing the releases of Ember Source every six weeks. Popcorn to Matt. Howdy everybody. My name is Matthew Beal. I'm an employee at Adapar. We've been using Ember for a long time since before 1.0, longer than I've been there. Fun thing I've worked on recently was right before my paternity leave for my second daughter. And right after she was born, a lot of work on getting Ember 4.0 across the finish line. Really, I just want to shout out Nathaniel Furness, Simon Imig, Serge Aspitov, Scott Newcomer, Bert DeBlock, Igor T. and Katie herself for helping us a lot get that across the finish line. It took a lot of people and a lot of lines of code were removed from the framework so I think everyone should be really happy with that progress. Only took us a little longer than we wanted but it's great to have out of the way so we can move forward. I'm going to stop myself there and hand things to Godfrey. Hello, I am Godfrey, work at Tilda and I worked out a couple of things in the past in Ember and lately I've just been filling in the gaps here and there whenever I have time. And in the last little bit, I've mostly been focused on breaking down the features. We have been embering into the smaller fundamental primitive pieces so that we can encourage more experimentation outside of the core framework and have been, yeah, that's been fun. So that's me and I will hand it off to Yehuda. Hey, I'm Yehuda. I also work at Tilda. Most, well, most of what I've been doing is having two kids during COVID who are under five but in addition to that, most of what I do in general is R&D, I would say, like Glimmer, Glimmer2, whatever. And so I've been doing two things. I've been doing a new R&D thing which we'll talk about later and just general Polaris planning, like a combination of talking to everyone about what their hopes and dreams are and just thinking about how to package it up and what the process is going to be. So that's me. I don't know a popcorn off the top, I guess. Hey, I'm Tom, I'm an ember developer with about 10 years of experience working in the framework. I work at LinkedIn, like some of these folks as well. And the thing I've been working on most recently that I'm really excited about is kind of what Yehuda mentioned, the little R&D projects doing some more exploration. For me, one of the big things I've been thinking about is how do you make data structures, data flow and the activity portable between frameworks? Fantastic, great. Thanks for introducing yourselves, everyone. Let's hop right into it to some of the Q&As that were pre-submitted. We're gonna start off, Yehuda, you'd mentioned something about Polaris and one of the questions is, heard here and there about Polaris edition, what's the process for planning Polaris? Question four, whoever wants to answer. I'll start and people can backfill. So I think the thing to realize about our general process is that a lot of everything we've done over the past few years has been around improving and formalizing our addition process in general. And so just to give a back of the envelope sketch of it, basically leading up to an addition, there's like new features that get added and then often a major release to remove deprecated features. And then the purpose of the process of addition is to figure out what features that have already landed or at least have already been approved that are in implementation work. Which of those is gonna make it into the addition? Because the purpose of addition is to polish up and reframe and re-describe what Ember is doing in newer terms, both for like better compatibility with how the ecosystem is talking about it, but also because over time things change. So the Octane Edition, for example, was highly focused on, I would say, the reactivity programming model and interoperability with native classes and glimmer components, right? So that was what the Octane Edition was for. And so if you look under the hood, there's like a million and one features and people could talk about what the status of them are. But at a high level, at some point, we decided glimmer components, native classes, a few other things are like the tent poles of this edition and we're going to make sure that we rewrite, when we do the documentation around those changes, make sure all those features are highly polished, any rough edges around that became stable but still need work are done. Anybody who's having trouble transitioning has code mods, right? So there's all these polish things around some central reframing, which is like glimmer components. I would say if you have to put it, say one thing, it's like glimmer components is the new component model of Ember is the Octane story, right? So Polaris is, that's what edition is, right? And so you can look at a lot of things like embroider or whatever as important, not or whatever, but important tent poles. The first part of the edition planning process is to figure out what is the big framing. So in, like I said, Octane, it was glimmer components are the new components. And I think Polaris is definitely going to have something to do with embroider, something to do with type script, something to do with finalize, like getting rid of all, no longer making Ember the object of requirement for like just doing basic things, right? So there's a bunch of things like that. And the first part of the process is like, how do you package that up in something that is like glimmer components are the new components? And then there's a project management process. I think for the people on the live stream, the most important thing to know is that there's a community, there's a process of community breakout sessions. Once we figure out what the rough scope is and what the rough slogan is, I guess, there we break out the work items into pieces and do community breakouts where people can show up and say, you know, I don't normally participate, but this, I really think that we need to focus on this aspect of the router or employer or whatever. And those in Octane, those conversations had incredible impact that really helped shape how we scope the details. So I guess look out for that. And it should be happening in the next few weeks or something, we'll start talking about that. The last thing I would say is we've had a lot of processes over the years. And my mental model for what we're doing here is we're converging around this like addition process and seasonal structure, which I'm gonna talk about way more in my keynote this year in EmberConf. And so a good way, like if the thing you're wondering about is not basic, I'll just be explicit. Like I think we used to have a more explicit roadmap process and I think that process has largely been subsumed in most ways by the addition process. And there's still some open questions about some of the detail that calls for blog posts and like the annual structure. But the reason that you haven't heard about that in a year or two is because the addition planning process has largely subsumed the purpose of that. Okay, at the end, for me. Okay, thanks. I'll jump in if I can, Carol. It's just one other thought because I'm sure a lot of people have like thoughts about the contents of Polaris, but just to talk about the like what we're thinking about in terms of how we plan it, maybe another important constraint is that we're trying to scope it so that we are able to ship something in months, not in years. And I think that's an important constraint. It's not gonna serve the framework well if we're like, oh, the next addition is the pie in the sky that's not gonna be around for a year and a half or two years. So we're trying to make sure that we are giving ourselves like achievable scoped goals and then we can ship that and move on to the next part of it. Excellent. Anyone that, thanks you Huda, thanks Matthew. Anyone else wanna add to that? All right, well, let's move on. We've got another question from that was pre-submitted. It says, so this one is maybe a little, here's how it goes. It says, it feels like core team involvement in EmberJS development slowed this past year. Is the core team baking something in the background? Are some people on hiatus or doing less open source software? Who would like to take it? You would like to. I will go first again, this is actually a personal question targeted at everyone. Well, target is a little pointed, but it's a question of everyone here. So people can feel free to say it. And I think that's the first thing that I would say is like with an eye towards like governance and team structure and whatever, there is always an ebb and flow of individual people. And at any given time, some people used to be more active or less active and other people used to be less active or more active. And so I think part of this is if you only pay attention to the ebb, then you don't notice the up and comer. So I think other people might have a better sense of who to call out there. But I think there are, while there are definitely some people who used to be more active or less active and that's like always true in every year of Ember, there are also people who are becoming more active and I think that's good. I'll just speak, but I also want to speak for myself, which is to say that I see my personal role in Ember, like I said earlier, as both a, like keep the wheels on in terms of the, like Melanie is much better than me. I keep the wheels on at project management and she ran the Octane project management. That's also true about Godfrey. But I try to keep the vision wheels on, like not just like the pie in the sky, but like what are we actually doing? What are we driving at here? I sometimes say like, we're pointing the ship in some direction. What is it? Right. And so a big part of what I do day to day is just like talk to people, like I said before, and that's very invisible. And in particular, right before the addition planning starts, it's like extremely invisible, right? Like we didn't, we have, the only people who know I'm doing any of it is the framework team. Cause it's all, it's like intrinsically a, it's not private in secret sense. It's private in the sense that I am having conversations with people one-on-one mostly, right? So that's a big part of it. The other part, as Tom mentioned, I've done historically like a bunch of R&D projects, the ones that are most apparent are glimmer one and glimmer two. I also did a pretty big refactor of like the parser internals, whatever like a year or two ago, that was like the equivalent of like glimmer 2.5 or something. And there's, there's a lot like that. And so there, there is an active project that I'm working on right now that you don't have to wonder about like you can go to my GitHub and I do almost everything in public. The reason you haven't heard a ton about it is just, first of all, from Ember's perspective, so let me just say a high level point, which is like every time I do a new R&D project for Ember, it, the purpose of it is to generalize something that Ember does so that it's less specific to what Ember is doing right now. So that it will be like more use, like more general than Ember's current status. And that has two useful properties. One of them is it's like better for Ember's future, but also it's better for things that are not Ember. And that's like, that's always been true about any of these projects. The current project like Tom said earlier briefly is like that, but it's like the generalization of our data flow system. So that both so that it will be a better foundation for Ember in the future, but also like so that it can be used plausibly in other environments. And again, the reason I haven't heard about it is because like the first few months of any of these R&D, like I probably for every successful one, there's like several failed ones, right? So I feel really confident now about this one, but that's only in the past few weeks that that's even true. So yes, first, like me, Yehuda personally, this is like it's important. That's why I started by saying there's a lot of people. That's me, Yehuda personally, the active work that I'm doing right now is an R&D project that has that flavor. But you should not like, sometimes I'm trying to be emphatic about this, like sometimes people look at things that like I'm doing or Robert's doing or somebody, and then they say like, oh, that's what Ember is doing. And that is like really cannot be further from the truth. I think people sometimes go up and like work on an idea, maybe it works, maybe it doesn't, maybe it actually, like the broader was like that, maybe it ends up being really important, maybe it doesn't, but that doesn't mean that like everyone else is like waiting for that thing or like everyone is working on it. That's not like a good way to think about what Ember is doing. So I'm just, that's just speaking for myself. Okay, that's, yeah, that's all I have. And I do want more people to say things because I think it's really important to know what people are. Yeah, just talking for myself, I think I've been a, I think pretty noticeably absent or more absent than usual, the last maybe six months or so, so time is not great, but this is how things work sometimes, just a lot of stuff going on, personal stuff, work, whatnot, sort of decided to re-evaluate how much time I'm spending additionally to work and sort of re-evaluate that stuff and re-balance some things. So I've been pretty happy with the amount of folks jumping in and sort of filling the void, that's been amazing to see. Like there's been no pause in development on things like Ember Temple Lent, which was previously a project that I did almost all the work in and a bunch of folks have just picked up all the slack there. It's just really great to see that and the same is true across many, many repos. I'm trying to also make sure that I've enabled enough folks so that no individual project is like sort of stranded. So feel free to reach out to me if you feel like that is happening and we can try to find out what to do. And this is not me saying goodbye or me out of the project. I'm certainly very much involved and still doing lots of stuff. I've just decided to sort of take a more passenger seat roll than I have in the past. I'll say for me, I definitely have been less involved over the past year. My literally my entire career has been working on Ember or Sproutcore prior to that. And I think I am so proud of the work that this team did on Octane. Octane to me felt like the thing that Yehuda and I were trying to build in 2011 but we didn't know enough and that the technology in JavaScript were not advanced enough. And this team is such a great team, a functional team, a productive team that it felt like a time that I could step back a little bit and catch my breath maybe. And also, there's other stuff going on in the world in the past two years that has affected a lot of people where they live, their family life, certainly their professional life and the great reshuffle. So I think it's not totally unexpected to see a little bit of uncertainty as people figure out how to navigate the new normal, as they say, but it feels really good to get the band back together and start exploring new ideas again. I just wanna use this as an opportunity to give a shout out to a bunch of folks who, some of them may be on various core teams but some of them are just folks in the community who step up and are really active. The people Matt mentioned who helped chip 4.0, like a lot of those are just really engaged community members that are hugely valued. Basically, what is Ember doing is not just a question about what a framework core team member is doing, right? And the whole project doesn't fly without real community contribution and we get a lot of that. It's been really great to see. I'm always impressed when we do something relatively future looking, like make the very first tooling for V2 out on when that happened. Before I even realized it, people I'd never spoken to about it picked it up and started using it, right? And contributing immediately back and we just, we get a ton of that. So in the engagement area, I think I've had the opportunity to be pretty highly engaged very recently and I've seen, for example, really good work happening in the adopted Ember out on Zorg because the community really comes together and steps in and helps take care of the things that we're all depending on for our applications. Even when the original maintainers need to hand it off and that's what you want, right? You don't want to be dependent on one original maintainer. And this is coming up because Ember 4 meant there's a bunch of work to do in the across the ecosystem and there's a lot of hands pitching in with that. And it's not to say that that work is done but an awful lot of it is in flight. It's really good. Fantastic. All right, thanks everyone for that. Kind of moving on into version 4.0. Now that it's released, one of the questions is what's the plan for some of the RFCs that were put on pause like enable embroider and set route component? That's for you. Yeah, I think there's a few things. I think we're actively pushing on a lot of those boundaries trying to pick up where we left off. Some of them just have a big sort of chunk of time where we were focused on 4.0 stuff but we're actively starting to pick things up. Things like single file components which I know is not the title of the RFC. Please don't hate me. The also set route template which I think probably needs a bit more work but I think is broadly in the right shape that we wanna go forward. Though I think that we need to contextualize that in terms of making sure that it doesn't conflict with future design and vision for routing layer stuff. And so there's still some considerations there. On the embroider side, I think at least internally at LinkedIn we've sort of changed tactics slightly from what we were originally doing which was trying to just land embroider in all the largest apps. And we've shifted to focus on landing embroider, sorry, migrating add-ons to V2 and of course testing and embroider and whatnot. Specifically because as we were updating those larger apps, it just turned into kind of a big pain and a hassle where add-ons were doing things that were not compatible. So we sort of shifted gears to do the thing that we have done in the past which is very similar to the jQuery migration we did where we rolled out testing and add-ons without jQuery first. That's why we rolled out testing add-ons with embroider safe and optimized a few versions back. And I think hopefully the next major milestone on the embroider side is making the V2 add-on format A in the actual RFC that people can talk about not the published format but the on-disk development format and B making that the default of generating a new add-on. I think those are the two next biggest milestones that we'll see. And I personally hope to see that happen the next month or two, though for the RFCs exactly when they land and when they happen like that's anybody's bet but I think those are the things that I'm excited about and the short answer to the question after all that rambling is, yes, we are actively pushing forward the RFCs that were sort of put on hold. When else wanted to hop in on that? There's kind of a related version four question that we got from our live streamers. Thanks so much for asking questions. This was given we've had a big upgrade to V4 and a lot of deprecation removals. Do we have a plan for more code mods or other tools to help people transition in the move from V3 to V4? We'd like to take that. I don't have an answer to that question as stated but I will say that code mods, the whole point of me framing Ember's structure as a seasonal structure is to show that... So code mods are really a part of the polish step in the addition process. And that is where you would expect the bulk of that work to happen. I think the only thing that's a little weird about the 4.0 removals is that... So in the octane, I didn't talk about octane. In the octane phase, all the changes were going to be removed in the future but they were significant, like going from curly to angle bracket. And in that case, we did the code mods during the addition and then a future major release removed those features. That's not how it has to work. That's just like one direction. And I think so that's... So the tackle question of like, are there any breaking changes that need code mods more urgently than Polaris is like a question for someone else? But I think you would expect to see a ton of code mods in Polaris. That's like where that work logically lives. Yeah, I think to the concrete question, I think that there is... Sorry, Ed, one sec. I'll kick it over to you. I think concretely, we will likely... So for a few things, obviously 4.0 happened a few, what is it? 10 weeks? I don't know exactly the timeline, but some a month or two ago and the next LTS hasn't released yet. I think we're still absorbing actually what the impact is and what the code mods might need to be done. Some changes that some removals were things that we, none of us were using or very, very few. So exactly what is painful for apps to upgrade and not is still something we're discovering. For example, most of our apps aren't gonna go to a 4.x until a 4x LTS exists. So we haven't really started that mega polish step because we don't expect massive apps to be migrating so quickly. Now, great if you did and there's awesome features you get small bite size, like reduced confusion. There's loads of good things. It's just lots of our apps just aren't on the cadence where they're trying to do upgrades every six weeks anyways. So all that to say, I totally expect more code mods. Some exist already, but I expect more to come out as we get closer to that first 4x LTS. I realized, I know I didn't want to jump in. I realized another obvious point, which is that I was just talking like literally about the code mods, but the thing that causes the pain for the most part is add-on compat and exactly what Robert said, we're very early. Now, we really try in both editions and majors to get a lot of the add-on compat out of the way before, like that's an important goal, but as a long tail matter, some amount of it gets done as the thing rolls out in real life. And I think so a certain amount of whatever the pain is right now it won't be there in six weeks or 12 weeks or whatever. Yeah, what I was gonna add was just, it might be interesting for this group even just to get a little concrete on the stuff in 4.0 and what people are seeing in apps that breaks. You know, the kind of things I've seen that come up most frequently, you who does write stuff in add-ons usually because you have, it's much easier over time to just clean up deprecations in your own code. I'm seeing add-ons using the implicit this removal is one that gets people definitely. That does have a code mod. I think it's a runtime, partially runtime powered code mod, right? But of course you got to do it. With the way to run it with the runtime assist and with the telemetry. One problem with it is that there's not a great, as far as I remember, until very recently there wasn't a template code mod for in your test. So oftentimes your test might be fine and the test might not have been code mod. That's right. I do believe that there's a PR or maybe it's already released. But it's released, it works down. Sweet. It's probably cold comfort for people but the very fact that it's so hard to code mod this thing is why we made the change. Yeah, why we had to get rid of it, exactly. Well, that's also an important point that I wanted to touch on as we kind of list out things about upgrades. You know, stuff that's very easy to mechanically see what's going on doesn't, we don't necessarily have to break it because it's easy to see what's going on, right? It's the hard stuff that we're trying to untangle. So it is, there's fundamental changes. I think that, I think we did a really good job at FORO. I don't think there's deep programming model changes and I think you've got really good defecation warnings on most of the stuff but it'll just, it will take time to get across the add-on ecosystem. Other stuff I've seen, like the global ember, the removal of the ember global is the other one that add-ons use definitely. And you know, that is important. It's a really important change that is people that ask a lot of future-facing questions about using faster build tools, using native modules or natively using ES modules. All that stuff is really conditioned on us respecting web standards, respecting the ES module spec. And so this is a perfect example, like why are we making you get rid of the ember global? Why do we have to go through add-ons and make them get rid of it? And it's because of that, right? Emberships as ES modules, to get an ES module, you have to import it. You don't just go grab a global. We just need to follow that rule. So that's another thing I'm seeing across add-ons as people upgrade. What are other people seeing, right? As like break blockers for apps. I keep seeing a send action is one that's been very easy to kick down the road and never handle it even in an app, but then it's everywhere. Yep. But also pretty impossible to code mod, I think. I think, Ed, what I hadn't thought about it like what you just said, but I think most of the breaking changes in these days are really about ecosystem integration. And I think that's both a true fact, but I think it motivates them pretty well because in your own life, you probably care about, like in terms of future-proofing, like if you want to break something, break the thing that's going to make it work better with the outer ecosystem, because if you have no choice, because then in a year or two from now, your code base will still work. I think that, like I have to think more about it. I think that's like the whole story, but it's... Yeah, exactly. And where we've really had successes is when we've gone all in on standards and just like our very early adoption of ES modules is really the saving grace that means you can do embroider and you can move forward with the vast majority of code actually being legible. Even though for a long time, that it has been kind of fake in the sense that it all got transpiled to different things that were not ES modules by the time they were running, the fact that we got people authoring in that format way back when it was a very new standard is what really puts it like, put us on such a firm foundation and just doubling down on that concept of sticking to standards. The same is true about promises too, exactly. Yeah, that's a good point. And then it was the same thing, right? Our promise implementation was not the built-in one, but we had one implementation. Yeah, and we helped make them. Exactly, and we helped make the actual spec and then when the spec was finalized, we adapted ours to match the spec and then gradually you haven't needed it anymore. You can use the native ones. So it's another example, yeah. So yeah, I think I do also want to call out, sorry, go ahead, yeah. I was just saying it's a good guide for the future and I think it does match what we're actually doing. So anyway. Yeah, I do also want to call out a thing that Rhonda LSE mentioned in the YouTube chat, which is that the code mods are a community effort. If you see a need for a code mod, make one. There's a code mod CLI project that lets you generate a thing that has a nice wrapping harness to make it very convenient to do. For example, you don't have to use that, but you can. There is EmberTemplate that lets you have template code mods that you can add fixtures for. I think it's very great. You should try it. I'm obviously very, very biased. But the point is all those code mods that are on like github.com slash Ember code mods, those are almost all done by community members. Sometimes me as like scratching my own itch about a given migration in an app that I was struggling with or whatever, but make a code mod. Reach out, we'll move into the org. The more the merrier, just like with the adopted Ember add-ons, it's very much one of those things where like together we can actually make code mods much easier to maintain. And the more of us that have a need and just, hey, I'll fix this one little thing, the easier it is for us, the rest of us actually do upgrades. That's one of the great things about the Ember community is we're all trying to build higher together. And so leveraging that energy and that effort, instead of just fixing it in your app manually, maybe make it a little code mod and push it up to github, others can use it. Great, kind of on a similar note in the world of contributions, somebody had asked before we started chatting here, that there's a limited number of people who know enough about Ember's internals to contribute. How can we open up to more contributors without weighing core team down so much that it's overwhelmed? We can delete code in Ember 4.0. No, I think that is actually part of it. Like some of the things that are the hardest to work on in the code base were the stuff that was obscure that I don't even think people realized was there anymore. Like you could still use a globals mode resolver for app.something to load up your Ember app. Like those kind of code paths and the complexity and the test suite to support that stuff makes it harder. And I think as we like to do the kind of the removals in 4.0, those things don't bring tons of value for apps. I guess I disagree with Robert. They don't really like unlock tons of new things for apps when you do Ember 4.0. What they unlock is our capability as contributors and maintainers of the framework to be able to do the necessary work for the next round. So I think that that's like one great way that we have like right now the code base is in a much better spot. We deleted 15% of the code base in the 4.0 process. So it's getting more manageable. And I think we're even said we're poised to be able to drop more stuff. Stuff is better isolated now than it was before because the sort of the way things sort of spread throughout and were caused to cross over module boundaries and whatnot was also very difficult to reason about. And there's even some stuff that we probably still need to continue pushing to get rid of. Some details around the older like CP observer model still are difficult to reason about. Chains and whatnot, those concepts are hard concepts. The newer activity model feels great for a reason. It is easier for the most part to think about. But even on that side, we have more things to do to figure out good debugging tools and good visualizations and whatnot for when things are recomputing and all that stuff. I think, sorry, go ahead. Oh yeah, my answer to how do you get more people contributing is in addition to all the things that were just said is to like double down on what's special and unique about Ember and then don't be weird where you don't have to be weird, right? So that's part of the point on trying to use more like leverage all the other big investments that other people in JavaScript make into JavaScript build tooling. ES modules is a standard. It's not an Ember standard. It's a JavaScript standard. Like if you follow the standard, you get more standard tools and just less custom stuff to maintain. And another example of that is that we've pushed hard on getting everybody onto Ember auto import, which is kind of a good polyfill for, I'm full the full embroider where it's just like use NPM the way NPM's intended to be used, not because NPM's perfect, but because it's big and it's got everything you want. And like the point of that is to like now there's a lot less, we can spend our effort on the unique and important things in Ember and not on just making an Ember specific wrapper for an awesome library or an Ember specific wrapper for some things so that you need not just add my library but add Ember dash my library and now somebody's gotta spend their time maintaining it, right? Like let's just be able to use stuff more directly and modifiers and octane plus Ember auto import being standard in the thing makes that kind of integration so much nicer. And we could just spend our time on making Ember itself be great and not spend our time on lots of glue and integration work. And I think that also is exactly the same thing we're doing in the TypeScript efforts. Like we're slowly sort of ramping and there's a bunch of our seeds for that. Those are also being, we're trying to work on those collectively but then even just internal to the repo, the better we can describe things with TypeScript just that means it's easier to reason about it. TypeScript has problems when the code is bananas and really create like not a hard to reason about and fixing those things and reducing those and making it nice typing wise usually just makes it nicer to for other people to jump into and work in and understand what's going on. And it makes editor integration nicer and all sorts of other stuff just better broadly even if you don't want to use TypeScript, I think. I think it's just a better overall thing. There's one thing I would add that he backs on what Ed said, which is that it is also true that breaking apart Ember and generalizing it helps with contribution. So historically, we did saw like glimmer but like more importantly like RSVP which we don't need anymore. And like those even back burner, right? We did it to some extent and we continue to do it. I think on top of just like use the ecosystem is good and like make our own code base better, which is good. There's also try to break it up, try to break Ember up so that there are pieces of Ember that are easily comprehensible and ideally could be used outside of Ember so that the contributor base isn't, there's like two benefits. One, the contributor base can be people who are not inside of Ember. And then two, those people will force you to not like get too coupled to Ember. I think that's all good because like tomorrow's Ember is not today's Ember anyway. And the one thing I want to add is like, I agree with what everyone already said but I think another way that we're doing it is by breaking down the Ember internal concepts and like basically exposing more of the capabilities in a more rationalized way. And I think as part of doing that, like we're putting up like, not just us but like community members too are like writing a lot of like seemingly in the weeds and low level RFC, but like if you want to, like for example, like we could have just built glimmer component, right? Like but instead we like the RFC that we actually did was the component manager RFC that like is like very low level in the weeds but it documented all the integration points between Ember and what like a component system or component class is. And like that is pretty good documentation for someone who's like wanting to contribute, wanting to understand how things work or just experimenting with alternative versions of like components, routers and stuff really good. I think we are like, I think we have more to do there and certainly we'll be doing more like in the area of like rendering the router. They're like there's the default cover manager, modifier manager, like, and I think like all of those. I think basically the like what I'm getting is like, I think would be great if the core is smaller and not so mysterious because like the thing that you get from like Ember out of the box is also things that you could also like implement yourself, right? Like, and I think that's just generally a better place for us to be and the RFC process serves as the on-ramp for like the potential contributors in those areas. Great, great. Thanks everyone. That was wonderful. Kind of on a little different note, what capabilities or features are the core team excited to experiment with in a post embroider world? Sounds like an ad thing. Okay, sure. I'm happy to keep talking. I was giving other people a chance, but I mean, I'm really excited that we're really and not even like, this isn't even super for you future thinking question. This is really a very near-term thing I'm excited about is making things in Ember very pay as you go because as of Ember four, we've put all the, once you get over all of the removals of Ember four and all the requirements of Ember four, there's nothing stopping us from shipping Ember four itself as a V2 formatted out on, which if you aren't familiar, it's just it's a much more static way to ship code and in a V2 out on anything that doesn't get imported from there just doesn't get into the app. And it's all what you'd want it to be using ES modules like as ES modules. And that's gonna mean that without a new breaking changes, without a FIVO, an app that just doesn't refer to certain Ember features doesn't have to have them in their app. If you don't use, I mean, that's not to say it's all automatic, right? There's work to do internally, like every Ember app has Ember object in it today because it's really being used, it's being used to back your routes and et cetera, et cetera. But the infrastructure is now in place that any feature you aren't using won't have to be there. And it means we can, means that people can, there's an incentive now to really do the work of decoupling things because apps will benefit immediately without having to wait for breaking changes and removal cycles. So it really, it creates new energy and ipetus to get land all that stuff now that the infrastructure supports that kind of thing. So I like that just because it means like a brand new app using all brand new patterns can be extremely focused and easy to contribute to, easy to debug because it will have less stuff going on in it, right? Without breaking the existing apps that need more of the legacy code who can pull it in when they need it but it wouldn't be pulled in until you need it. To make a very, like a maybe overly general statement, there's a lot of things that people want like server side rendering, edge rendering, code splitting, there's a whole bunch of features that I would say like are bucketed into like things that performance minded people claim is good about other ecosystems or whatever. And I think Ember has actually done all the, almost all the legwork inside of Ember's framework itself to make that stuff work. And like many people, many ambitious people have, for example, made SSR work in some form or another with a lot of work at the bundling level to make that good and have to deal with code splitting. I think for me, this is like, what is good about Emboider is that it takes all that work that we already did, like sometimes years ago and makes it possible to actually just plug it into the place where that would make most people use it. So like things like route-based code splitting, tree shaking, being able to run things at the edge, being able to do SSR, like all these things are, it's gonna be like a, like it will be a quantum week improvement because the Emboider thing is kind of like the last domino in the work that we largely already did. We got five minutes. Oh yeah, go ahead. Sorry. I can absorb five minutes easily, Carl. You know me. I was gonna go lightning round real quick. Don't even worry. Y'all missed the question. It was a post-Emboider world. So not embroider stuff. What's the stuff you're excited about after embroidering? That was the question. So you gotta pay attention to the question. What is good? Yeah, yeah. I see. I want builds entirely in the browser that do everything that our code base builds do. I want the thing, the ed-demoed at EmberCon, that Moe, I think Moe? Yeah, exactly Moe, which is still an experimental level thing, but it's what I'm excited to use once Ember is all on 100% ES modules to like that. Zero cost builds. It's very hard to motivate. Like I did the original prototype and I made it work for a demo. And like that, it's very hard to motivate doing continuing to invest in that in the Ember space right now before embroidery lands. Like you can do it. And it like works for, it's easy to motivate a demo. All right, Carl, hit us with some lightning. A few, here's really quick ones, either one word or one sentence answers. Have you all been looking at some of these newer frameworks like Next and Remix? Yes. Yes. Do we have anything to learn from or pull in and steal? Yes. Yes. Great. Always. Great, please. You will be assimilated. You missed all the matters. When will Ember CLI support the current node LTS? One, one. You need one. All right. So, soon? No, I'm kidding. That's my reality. Soon? Soon as it goes. Is there a release date for the first 4.x LTS, probably 4.4? I'm interested in the Ember video chat. Katie knows the date probably, but it's just six weeks of release cycle. It's gonna be 4.4. And when 4.5 releases, 4.4 will be LTS. So do counter math. I can't do it. Sometime in June. So it'll be before 4.3.28 loses its LTS, but. And how about an opinion question? Is everything moving towards derived data patterns or should that happen? Unknown and yes. Fantastic. Jen, should we, I think it's about time. Should I hand it back over to you? Yeah, that'd be great. Thank you so much, everybody. That was great. Yeah, thanks everyone for this Q&A session. Thank you to everyone who submitted questions ahead of time, who submitted questions live. I've got your questions here. We've got a list and you can expect to see you over the next few weeks. And the Ember times we're gonna try to hit some of those other questions that we didn't get to, or that just didn't fit the format for a live Q&A like this. I'd also like to thank Carl as our facilitator. For our listeners, anyone who wants to stay current on what's happening in Ember, you can read more at our blog, which is blog.emberjs.com. You can subscribe to the Ember times, which features information about what's going on across the whole Ember community. There's also some upcoming events happening online within the Ember community in the next few months. We got things like Ember comp, Ember ignite, there's meetups happening. So if you wanna connect with other people, please visit emberjs.com slash community. And you...