 I'm going to go right into it. So as we just heard, Yahoo! Just Talk covered the what. I'm here to cover the how. And so I've called this the art of change. And really, you could use this as a title for all software engineering. Because software that doesn't need to change doesn't need you, and it doesn't need me. It's all about managing change. That's the real art in what we do. And I think most of the developers in this room have had the chance to learn and to be trained on the basics of managing change at the scale of an application, managing local change, basic stuff, like how you source control and code reviews and pairing and continuous integration and testing to manage the state, to manage change in a way that makes the cost of change and the impact of change manageable. You're breading your butter, and that's what you do. But I think a thing that people don't get taught and don't often have the opportunity to master is how you scale that change up beyond one application to a software ecosystem, to a whole platform. And so I want to start with a quick crash course in how to think about change at that scale, because it is definitely harder than going it alone and just worrying about one application at a time. But that's where the leverage is. So if we think about characterizing change, the simplest way that people might first think about characterizing change is just asking how fast should we change? Should we go slower? Should we go faster? If you go too slow, you can't adapt. If you go too fast, you break things and your community can't keep up and things get bifurcated and your users get mad. So I'd like to suggest that that's the naive approach to understanding change and it's not really accurate. There are changes that happen slowly that are still hard and there are changes that can happen quickly that are easy. And there's a more nuanced way to think about change. I like to suggest three ways we're gonna categorize our changes and think about them. I'm gonna call the first one cost scaling. And I'm gonna borrow some terminology here from big O notation from computational complexity theory. So if n is the size of an application, the distribution of all the apps on your framework, some of them are small end and some of them are big, what is the cost of the change we're talking about making? Some of the best kinds of changes are, or one changes, that's a constant cost. It means the cost is the same whether your app is small or whether your app is big. And that's a really great case. An example of that might be taking a feature out of the framework, so that's a breaking change, but immediately reshipping that feature as now an optional library that people can just add back in. Still a breaking change, there's work you have to do, there's steps, but the steps are the same whether you have a tiny app that you started yesterday or a massive app that you've been working on for 10 years. That's a really great case when you can make that happen. But a lot of changes cost more than that and so don't scale at constant. They'll scale linearly. This is the kind of change where something like if you have a big application full of Ember components and you wanna change them all to Glimmer components, your cost scales of your application, that's a linear cost. And there's a worse kind of change which is if the change causes subtle differences to the interactions between things, interactions between components, interactions between disparate parts of the system and different models, your cost can go super linear and now you're scaling very badly, it can go n squared or worse. And these changes can become just completely impossible to do as soon as the app gets beyond a trivial size and we try not to do these kind of changes, of course. So that's the first dimension I want to use as we characterize change and how we think about paying for it and how we think about designing our software to not do the worst cases there or how to trade off different kinds of strategy. So the second thing I wanna talk about is locality of change. What I mean by this is some changes are very local and some changes are very global and a lot of those are just fundamental. Something like upgrading Ember is a global change. You can't upgrade Ember for one component at a time for one route at a time. You can't upgrade TypeScript for one module at a time. Those are global changes and so because they're global we have to use other techniques to plan very carefully around those changes. The contrast to that is changes that have really great locality. We saw a bunch of that in the previous talk, things like the interleaving examples where many generations of technology can interoperate but what that means in practice is you can pick any one component in your application and decide to upgrade it today and the people who depend on that component don't have to care and the components that your upgraded component depends on didn't have to care you got to do it independently. That has huge benefits because on a social level you don't have to sit around waiting for other people to upgrade first. You're not working in series, you're working in parallel. Everybody when they have the opportunity can push things forward and at a purely economic level you can now amortize the cost of that change. You might still want to eventually upgrade all the things. That's a good goal. It's good for the coherence of your teaching story making sure your team understands how everything works just having it nicely all looking the same is a good thing but you can pay that cost gradually and when you need to and when you have the opportunity to and just like a financial cost if you can pay something slowly when you have the opportunity it's way easier than having to pay it all at once. So the third thing I wanna talk about for characterizing change is the durability. What I mean by this is that changing from a less durable pattern to a more durable pattern it's a really important consideration when you're deciding on whether a change is worth it and what changes to do. So what I mean by durability is nobody can see the future and all software needs to change so you might ask is durable software even a thing? Is it possible? I'm gonna argue it is and it's not because durability means never having to change the code. It means that code that you write depending on a library, depending on a framework gets to keep its meaning even when that framework changes because there's been a good standard in between you and that implementation because there's been a good abstraction barrier between you and that implementation. This is nuts and bolts software engineering stuff but it's very difficult to do. Seeing the distinction between interface and implementation it doesn't come naturally. It's something you have to work at and one of the reasons it's hard I think is that some of the best done cases they're invisible to us when it's done well. It's the kind of thing that you notice more when it's done badly and the best examples of well-separated interface and implementation you take some for granted that you don't forget that they're even there and that there even is an implementation apart from the interface because you only think of the interface. So an example of a change that we did in octane era that is a super durable change was adopting standard JavaScript class syntax all across Ember. Originally we didn't have that because we're older than JavaScript syntax class syntax and we helped codify it into the language so that it would be there for us and then we finally adopted it and so that kind of a change it has definitely has a cost there was a lot to do in terms of updating code implementation documentation teaching but it was a worth it change because now we're on something extremely stable the durability of a spec like it's in JavaScript is something you can trust you can feel good about that change. There's smaller examples too things like the building block concept that you could do is talking about things like our component manager boundaries those are low level interfaces that are very stable that are keep the implementation details apart and that's why we're able to do what we do. So that was the third piece of thinking about change so now I want to apply that to the features we've been talking about for Polaris edition. And so the first thing I want to talk about is template tag. So visually and in terms of your experience writing Ember apps template tag was a huge change to Ember can we ship this? And well we already did in one sense in that you can absolutely use it in your apps right now it works in Ember 5x it works in Ember 4x it works in Ember 3x it works with prettier and ESLint and VS code and new of them the Ember RFC that defined it got went through the whole consensus process is merged we were committed to supporting it that sounds pretty done, right? But hang on I think I probably have made some folks in the room a little uncomfortable because we want a higher standard than that, right? We don't call it done if it's not in the guides we don't call it done if it's not in the docs and there's not a tutorial that would let you discover it and it's not in the blueprints and quite possibly even created a code mod to get you to it, right? So I want us to feel both motivated and proud of all the things we have in fact shipped to a standard that is frankly the done standard in a lot of other places. But we are still going and this is where all of you come in which is that these things work now is the time when us as a community by adopting them, learning them, trying them out, kicking the tires your experience picking up those features is how we're gonna get that polish you're gonna be able to help us fill in those docs because you're gonna try to use it you're gonna find something that wasn't in the docs and you're gonna help us get it there. So this is my call to action to you this is a feature that is very much along the technical pipeline of being done done but we need to work as a community to get the polish that we need and everybody in this room is really well positioned to be a part of that story. So and one very concrete way you can help push the adoption story on this is that GitHub's not gonna syntax highlight our GGS files until there are enough GGS files in existence on GitHub. So go and convert some files. Let's talk about what is it, what is the cost of change look like for getting the benefits of template tag in your application? What can we say about that kind of change and characterizing that change? Well, from a locality standpoint it's got our typical good locality story, right? You can pick some component at random in your application and convert it to template tag and you don't have to worry about who calls you and you don't have to worry about what you call it's gonna work and it's gonna interoperate. So that's really nice. There is a little bit of non locality which is that when you go to template tag you do have to figure out where you're gonna import your dependencies from which is not something you used to have to do, right? Classically there was just a bunch of conventions and they could be very opaque. You had a helper like this one and if you looked at this template and you didn't know anything about Ember Intel or what T is, how would you know it came from Ember Intel? With template tag you would know that now but the transition does mean you gotta discover that, so this is something where it will get easier the more the ecosystem does it an add-on like Ember Intel will want to actually put this in its read-me now because now this would be the way you'd get this thing and of course you can help with that in the read-me. Thankfully these things are very conventional it's usually not hard at all to figure out what to put here because the blueprints that the add-ons themselves have been using to generate these things have done this in a stable way for years and years and years. So some add-ons do weirder things but the vast majority are gonna be extremely guessable like this one. It's also very possible to answer this question automatically the vast majority of the time and have a code mod to do this transformation. I know there are definitely folks working within companies who've got their own and have talked about open sourcing them. I think also that a bunch of stuff I'm gonna talk about in the under the rubric of Emberator is effectively already doing a lot of what a code would have to do here. So if you're interested in helping work on that that's another really awesome call to action for the community to help us take the cost of this change from one that is order N linear in your application, right? Down to something that could really get close to order one of a constant cost of just run the code mod. Now I say nearly because there are a couple things to be aware of, good things but ones that do require a little attention. And the main one is that template tag opts you into strictness in a couple of ways. And really the only way that's super relevant anymore because I think all the other kinds of strictness that it implies are things that we deprecated already but there was one left which is the component helper taking strings, right? This is how it has always worked. It used to take strings. Once you go to template tag, that's a runtime error. And so this strictness is very good. We're gonna talk about it later why it's good and why it unlocks our ability to very much analyze applications reliably. But it's an example of one of the few things where this change is not exactly constant cost even with a really good code mod. You'd have to look at these cases and pay a little attention to them. All right, so one final thing I wanna add about template tag is that I'm very happy that we've now stabilized the low level of pure JavaScript implementation template tag. The idea is that the syntax is really important for your developer experience. But when you go to publish that code to the world, say in an NPN package in a library, it's very nice if it's standard JavaScript syntax at that point so that all the tooling out there can understand it. I'm very happy where we landed after a consensus process to have a really good low level representation which we stabilized, we got consensus on the REC and then we very rapidly implemented and we have a fully Rust based compiles to a WebAssembly transformation library that goes from template tag to standard JavaScript that's just pluggable and is gonna be able to power all the tools that need it. So that's pretty new, we just shipped it. We wanna get that into all the tools, things like, you know, classic Ember CLI, Embruder, add on authoring tools, Ember template, Glint, right, all those things are relying on the first version of parser that we have which was the spike that let us get as far as we got. But by having a fast but complete JavaScript parser here, we can get just like squash a whole bunch of long tailed bugs that won't come up again. So I'm very happy about that. It's the kind of low level infrastructural stuff that seems kind of low level until you realize how much leverage it gives us and why we're able, why these things that we wanna ship that sound so ambitious are really not that far away. So shifting to the next feature, talking about TypeScript, first class TypeScript support in the framework and where that stands. This is another thing that's really far along. We shipped the first party types as a preview in Ember 4.8 back in September. We shipped the stable versions in 5.1 last month. And right after that, there was a flurry of updates to all the ancillary kinds of packages and add-ons that are common and that needed updates. And it's humming along really well. So, you know, TypeScript's not mandatory. We're committed to always designing a number of APIs that make sense in plain JavaScript. But if you want it, it's there. And even if you don't use it, your IDE is very likely to benefit from it and give you better feedback and better completions. And it's just a benefit to everybody that detailed information about our code is available. This has been a very steady community effort. Then it's very far along. It's a huge thanks to our TypeScript team and everybody who has helped with that. When you think about the adoption story, how do you think about this particular feature and categorizing the change and what does it cost to take advantage of it? So if you don't already use TypeScript and you want to, the fact that there's now stable types in 5.1 makes it a really good time to start because you can build on that. And your adoption cost there really is, it's the standard TypeScript adoption cost story, which is a pretty good one. If TypeScript's designed around that, that's why it's been successful. You can start small and build out how much of your application is in TypeScript. And if you've got backwaters that you don't even touch, they can stay in JavaScript as long as you want it to and you can deal with that. So it's a very, again, it's a change with good locality. It's not like perfect locality in terms of interleaving. It's more of one where you do kind of want to work from, ideally from the leaves inward, for example. It's nice if, because it's nice if the things you want to depend on already have types. So there is a kind of optimal order to do TypeScript adoption. But you can always skip the optimal order if you want to write a few types by hand too. So it has good locality. If you, so that's if you weren't using TypeScript already. If you were and you're using all the third party types on definitely types and now you're switching to the Ember ones and you want to get the benefit, what is that going to cost you? It's pretty easy. It's not an O1 cost because if you have a ton of TypeScript you're going to have more things to look at. But the differences are small. Because remember the definitely type packages and the Ember packages were very much trying to model the same exact things. The differences between them are small and not very complicated. And so the change is like O and with a really good constant factor. It's very affordable. And a nice thing about it is that the TypeScript compiler exists to tell you exactly where you have to look and make changes. So you don't spend a lot of time hunting around for what's not working. So definitely a feature that you can benefit from immediately. All right, so I've been talking about TypeScript, check type checking in your actual TypeScript code. But our story is not complete unless we're also checking types all the way down through your templates. And so that's what Glint is for. Glint is the language server that can understand not just TypeScript, but also TypeScript all the way through your Ember templates. And good news, Glint shipped a 1.0 release back in April. I've been using Glint in multiple real applications. As an early adopter I definitely saw bugs. But we are now well past the tipping point where the benefits I get out of having Glint helping me well outweigh the occasional hiccups that we're still fixing. So this is the same story I was telling about some other stuff, right? It is very much usable for the kind of folks who are here in this room, it's a great time to get involved, to try it, to learn it. Because your efforts there are what's gonna help us give it the last polish it needs so that it becomes a tool that is out of the box in the blueprints, in the docs, very easy for people to adopt. An area where we could really use a small amount of community contributor effort going a long way is really consolidating our tooling story. It's like we can have one package that gives you all these things in VS Code or pick your editor of your choice. To curate, the features all exist but today you have to know a little bit about setting them up. We really need to just make it easy for everybody. So it's that story. Let's work together to put a bow on it, get it thoroughly documented and get it at the door to everybody. As far as Glint and how do you think about paying the adoption costs for Glint? So Glint has huge synergy with Templatag. It makes a lot of sense to adopt them together. And the big reason for this is that, of course, Templatag makes you import all your dependencies which makes them immediately visible to TypeScript. It all works out very nicely together. You can use Glint with regular old handlebars files. You don't have to do it with Templatag. But if you do it with regular handlebars files, you do a little extra work to register your types in the global type system. So my own personal suggestion is to do that together. And it's a very nice process. And so that means that the adopting Glint story is the same as the adopting TypeScript story. It's got a very good incremental process. You could write new code in it and work outward to the things that you want to have types. And if everything doesn't, that's okay. So you get to pay it, it's got good locality and you get to use it right away and not worry about doing your whole app at once. One thing where there is like a non-local effect and cost of change for Glint adoption is you definitely have an easier time if all the libraries you depend on already have good types and good types that work specifically in Glint. And I wanted to point out one thing which is that even Ember add-ons that shipped types in the past might not have, in a pre-Glint time, they didn't have to say anything about what blocks they accept in the template or what element they expose. And now they can say that and they really should say that to make them very easy to use from templates and from Glint. So this is a call to action for all my fellow TypeScript fans out there. If there's an add-on you're using and it doesn't have types that declare the blocks that it yields and the element type, it's a pretty easy fix to that add-on. And if you can make that PR, you're gonna speed everybody's adoption. All right, shifting into next feature set. This is the one slide where I've kind of summarized the status of Starbeam Universal and the fact that new writing's built on top of it. And Yehuda did a good job on this already so I don't think I'm gonna spend a lot of time on it. The idea here is that this is the first thing on my list, actually, that's not something you could literally go and use today. All right, so we got pretty far before we hit a feature like that. That's pretty good. And Starbeam, as a library, exists, of course. Like you can go read its docs, you can go read its source code. It's not just an idea, it's very real. We definitely think that because its core is really designed around the same ideas as the tracking we've already got, the integration's not very difficult, but we need to do it. And if you're fascinated by that kind of stuff, that's an excellent opportunity to get involved and collaborate on that. The interoperability story here is pretty fundamental. This is the kind of stuff where if you don't get interoperability right with a reactivity system, for example, that can rapidly become one of those O-N squared kind of changes. If you can't be sure that changes in a tracked property are gonna be reflected and through changes in a Starbeam universal resource, that's a pretty hairy problem to sort out and figure out. So, but the good news is that the integration here is very, very deep and it makes the interoperability very, very stable because they're gonna be powered by the same core. It's the same ideas that power both. Once you've plugged them together, every change in a Starbeam resource is visible to every tracked property. Every tracked property is visible to every change in a Starbeam resource. Glimmer's gonna re-render the right thing at the right time. All right, moving forward on features. I'm gonna talk about Embroider now. This is really the rubric for the build tooling and the authoring format. So, I should clarify what we're trying to talk about. So, Embroider is our project to bridge the gap between our legacy build system and a durable spec-based, module-based system that's broadly compatible with the rest of web standards and de facto standards of the software ecosystem of the day. Embroider is necessary because of three key problems. And these are really places where just in the past we didn't do as good a job at the core values we've been talking about, things like implementation interface separation. The key problem here is that add-ons, when first introduced, didn't get that process. We didn't do a spec. They're extremely implementation-defined and they leak implementation detail all over the place. And so, it has made it very hard to disentangle them and move people together forward. And so, it seems like we're in one of those traps you who was describing where once you've leaked all the implementation details, are you stuck forever, do you have to fork the world? Embroider is our answer to that because we think that it's worth investing the effort to not fork the world. We think we can do it. We've invested a lot of time and energy characterizing all those behaviors and putting them into a tool that can automatically convert the old to the new. And it can't get it 100% because there's just some really wacky and dynamic things the old world can do. But by getting you most of the way and highlighting for us where the manual work is, it has dramatically reduced the cost of getting our whole ecosystem across. It's really about bending the curve on the cost of change. So, what do I mean by that? So, thinking about durability of change, right? The problem was we didn't have a spec and so our add-on format was very not durable. Well, so Embroider, the very first thing we did was write that spec. So there's a clean and minimalist spec for V2 add-ons and it just goes all in on ES modules and standards. And so it's durable, right? We can feel good about those add-ons even if the implementation that we're gonna consume them in changes a lot of times. We can be confident that we're gonna be able to process those add-ons. We also improve the locality of the change by allowing everybody at a package level to do the kind of interleaving strategy we've been talking about at a component level. What I mean by that is, you as an app don't have to wait till all your add-ons upgrade to the new format. You can start using Embroider right away and rely on the compatibility layers that make those add-ons, the vast majority of them work just fine under Embroider. And maybe you'll identify a couple that don't and those will be of the blocker and that'll let us focus our community effort on those few ones. Rather than trying to rewrite them all before you could even do your first test of your app under Embroider. And in the opposite direction, as an add-on author, you really want to get your stuff in a new format but you don't want to break all the apps who haven't ready to upgrade yet. So we've also made sure that the new format add-ons can work seamlessly in all the classic apps. And so we do that by, effectively, you can think of Ember Auto Import which is a dependency on every newly generated Ember app now as our polyfill for the full Embroider in classic applications. So it gives us that working in parallel, not in series benefit that you get when you have better locality. So the status of Embroider is that it's definitely a thing you can use today because there's actually many applications in production on Embroider and some of them have been for well over a year, maybe more than one year at this point. I mean, we've been chipping away at the compatibility problem a long time and the more ambitious early adopters went in quite early and they were mostly motivated by teams that were very motivated by wanting to improve their end user performance through code splitting and tree shaking to a degree that they just could not do on classic builds and they adopted Embroider early, dealt with the fact that there was definitely some add-ons that were tricky and they had to deal with it and we had to sort through them but they're on Embroider still and happy and have been in production for a long time now. So we've had a lot of experience making sure these apps work and each time a team has done that they've helped us shave down the rough spots a little more. Today's stable releases of Embroider ship with Webpack is the default bundler. Webpack was a really good first stepping stone for us partly because it's relatively loose with its intercompatibility between ES modules and CommonJS and AMD and that was important for trying to get cast to the most polyglot net of all the kinds of things that our add-ons are doing. And also because it is a bundler in the classical sense that the same thing that our classic build is meaning like it takes all your code and gloms it together and serves it out we could make it just be an implementation detail of our classic build. You could stick it inside of your broccoli pipeline and still run all the same commands and still run all the same tests and it just fit in there pretty nice. So it was good for adopting things but the point of Embroider is not to lock us into any particular build tool. It's to define a durable standard for MRAP authoring that's easy to port to any system that follows these standards and conventions. And so I'm happy to report that our investments in that portability are paying off and we're rapidly approaching the first preview release of Embroider as a V-Plugin. V is exciting because it takes advantage of ES modules directly in the browser to give radically faster developer experience. I would say the benefit here is that up till now Embroider has definitely been a big boon for end user performance because we can optimize builds beyond what Classic could do and that has already been a benefit for apps that really care about that. But this gives us the other side which is optimizing the developer experience speed as well and doing something much faster than Classic can or will ever do because it doesn't bundle your stuff at all in development, right? It serves the files individually. When you change one file in your app it retrans files that one file and touches nothing else and all the rest is cached in your browser. So it's really impossible for a bundled build system to go any faster than that. So let me show a quick demo recording. I'm sure it's not gonna be easy to see all that detail here but the general idea is this is code you could run today in the Embroider repo. We have a demo quality setup with a V app. This is really like a couple of weeks tinkering on top of all of this high-level infrastructure that we've already got. We have, we saw the V config file go by there. It's not that long. It imports a bunch of core utilities out of Embroider. This is a pretty stock Ember app but it's got about 50 Ember add-ons in it because that's what you get in a stock Ember app. It's got all the Ember data packages and they're working. It's got QUnit and Ember test helpers and Ember welcome page and Ember welcome page styles and its assets. And all those things worked on Veet and this app has GJS and template co-location and so the pitch here is that this is, it's very close. This is demo quality just cause like if I had another two weeks on the clock I probably could have had a thing like it's an actual release that you'd use this time. But we invested in the infrastructure and now this stuff is very, very doable. So I'm super stoked to ship this stuff. We are really, really close and I'm very excited. So our goal for Polaris Edition, thank you, thank you. Our goal for Polaris Edition is to support fully typical heat usage, which means you'd have sub-second development start-up times and nearly instant rebuilds. So the idea would be that that should be the out-of-the-box experience on a new app that's not doing anything legacy and if you still need the legacy stuff you can still use it but you're gonna be able to turning on more of the compatibility layers and paying a little of that cost. One thing that was in the demo video and it's probably hard to see on the little screen is I was running two different commands there separately. You can of course combine them but for purposes of making it more visible I showed them both. One of them is a pre-build and that's where all of the broccoli stuff goes. The stuff that we still need for turning all of those 50 add-ons were mostly V1 add-ons they needed to run their custom stuff right on. Because there was a mutation to find an add-on's not really like a library we can look at it's really a program that prints a library out to us so it really does need to go through the old system and that's what the combat layer is doing. That's the old code and the broccoli code. Thankfully that's a very shallow broccoli pipeline. We can do every add-on independently so it's significantly faster than the full builds of broccoli that you've got and then that feeds into the nice build tool and the default experience would be just the nice new thing and you could turn on the combat stuff when you need it which is all about the how do we pay that cost incrementally to get you on to it. I think this is a realistic goal to have all this working really well in the Polaris timeframe which is soon. It's months and not years, right? I think it's realistic partly because of all of these things that we've already shipped and used successfully in real applications and it's also, I'm very optimistic and it's realistic because the community has really, truly rallied behind this project this year. We've had multiple companies stepping up to help sponsor development on the project. We've had multiple individual contributors have come together on their own time, some of them as part of their work time and so we have a really healthy and growing core team of contributors making this stuff happen. This whole project has really grown from what was just a side project of mine because I really cared about solving this problem and I could only go so fast to something that's really got a lot of capability and is still accelerating as we're ramping up people and who have the luxury now of spending a significant chunk of their working days on this problem. So it's looking very bright. I have a URL at the bottom there to main matter and brighter initiative. Shout out to main matter for helping organize a bunch of that work and helping find these companies, wrangle them and get everybody to step up and really help accelerate this project dramatically. So what's it gonna cost for you to adopt this stuff into your application? Let's think about the change class again. Our goal for app authors is that normal app code like the vast majority of app code really is an 01 change. You're gonna have to change config files. You're gonna have to change some stuff in your package JSON but you should not have to touch all your components, all your routes, all your templates. All those files should stay the same. That's pretty much the point of this project is to make sure that these costs don't grow with a size or application to the point where it will be impractical for you to use it. So the main thing that is gonna let us pull that off is whether we can rein in just primarily behavior in add ons that is just not compatible with an ES6, ES modules world anymore, right? Or it will never was, right? Never was compatible with ES modules. So what do I mean by that? Well, so the first thing that I have on my list here is you should expect to see a deprecation coming down the pipe for require and define, our AMD loader. Those are implementation detail that leaked and they're very useful because they're very flexible and so they're used a lot. And so this is a change with expense across. It's not the kind of thing where apps have thousands of places calling this thankfully, right? It's not that kind of a cost but you probably have two or three or four add ons that do this in one place, one critical place that we have to help find solutions for. So there's no deprecation RFC for this yet. Expect to see one. And if you are one of those people who's relying on those features, we'd love to hear your use cases in that deprecation process. So you could say, well, what am I supposed to do instead in this case? Let's make sure we design that into the future world so that it meets those needs. And so that the conversion process is a smooth one. The second thing I listed here is we need to deprecate and break invalid uses of ES modules. What I mean by this is for a bunch of historical reasons, you can write invalid JavaScript and it works today. And this is one of those things where it's much better to accidentally break something that's supposed to work than to accidentally make something work that's supposed to break, right? Because if you break something that's supposed to work, somebody notices right away and deals with it if you subtly allow invalid stuff to work, it propagates and doesn't get fixed. And so you will definitely find this. If you try to take a significantly sized number application today and run it in that VIT demo, I bet you will find a couple of places where this happens. And so examples of this are importing a name from a module that's not exported from that module. In our traditional build, you get that variable back, it's just undefined. In the actual spec, if a browser does it, that's a syntax error. It's as if you had an enclosed curly in the file, it's just not okay, it will never run your code. Another example is mixing up the default export of a module with the module scope, like basically import star from versus import from. Those are different things and our classic build pipeline conflates them. And so you will definitely find places in add-ons or apps that make that mistake. So these two things I highlight as part of the cost that we still, the last bits of tricky cost that we have to work together as a community to solve, they're definitely gonna impact add-ons, primarily add-ons, some apps, and of course the apps that are impacted are gonna be the ones who are filing the bugs on the add-ons saying I can't use the cool new thing, please fix this deprecation. But I wanna make the pitch that this is a really strong argument for a durable change, because what we're talking about here is making sure everything we do and everything we have follows the ES module spec, which is part of the language, it's as much a part of the language as constant let and class and try and throw and catch, right? You can rely on it that much. And so by making sure all of our stuff follows that pattern, we're gonna have a very durable system. What that means is we don't have to just be happy that we're targeted to beat and we got to beat because if eight months from now, there's something even better, we will absolutely be on that too, because that thing's not gonna succeed if it doesn't understand ES modules, and ES modules are a very durable standard. So that is the pitch, why it's worth going through this together as a community and solving these last little tricky issues that are gonna make it possible for all of us together to get over that hump and be in a really happy world where everything is following standards. And it puts us on a real path to sustainability in a way that goes beyond just saying, we can use the same, we can use some cool tools and we can improve our developer experience and we can have a nice competitive story because it allows us to focus our efforts as a community on the unique value proposition of Ember. We can focus on the stuff that we are good at and we can stop maintaining custom stuff that is outside the realm of what's important, right? Maintaining a custom build pipelines is not actually an important thing about Ember. It's not what makes us unique and successful and it's not a community value. So it's just a drain on us to have something custom. We have to pick it, we should pick and choose and invest that effort into the stuff that's really good about Ember and then all the rest, let's be standard. It's another form of doing it together, which is doing it together with a wider ecosystem. So I'm very bullish on that ability because if you think, if you look at a first glance at an ecosystem, all the stuff out there that is, many, many add-ons exist, right? And like all open source code, people publish stuff and then they move on and so not everything's well maintained. That's okay. A lot of that stuff doesn't have to come with us to the new world because a lot of that stuff is doing things that you won't need, right? A lot of stuff we did historically in add-ons was like take a particular third party library and wrap it up for Ember and get it into your build. Like that's not a thing you need now and for anymore. You don't have to worry about the cost of bringing all those add-ons across because it's just so much easier now to use this stuff directly. We've solved a lot of those problems and we don't need to cast such a huge net and maintain such a huge amount of stuff. So I'm bullish about that too. I'm really excited to be able to really see our community rally around the core of what is Ember and what makes it really good and not dissipate our energy wider than we need to maintaining stuff that we have because we legitimately needed it back in the day, right? Because there wasn't a better alternative then but now there is, so. All right. The last thing I'll say about Ember at adoption cost is that we can now give, because of template tag, we can now give add-on authors very clear and simple advice about how to make sure their components will be analyzed correctly and statically by Emberator, right? This is an area where we've got a bunch of infrastructure to try to make it possible for, no matter when your add-on was written, we can write rules about it and we could use little helper things like the ensure safe component tag helper to try to explain to Emberator where are the holes where this thing might go and grab a whole extra component and I'm gonna miss it and not get it analyzed into my build. The story is as an add-on author, just use template tag. That solves all the problems. You'll never have to worry about that again, right? Because template tag is designed to solve this problem. So if you use, this is the slide we showed earlier showing the difference between the stuff that works and doesn't work now in template tag. Strings can't accidentally resolve into components anymore and that was the hole. So if you just adopt template tag, there's a whole code path of compatibility and rules and stuff that we don't need. We just turn it off for your add-on, for your particular component, I mean. And it will just work for all your users. So as an add-on author, definitely go ahead and do it because it solves all the problems and now it's a very easy story to solve. Cool. So Yehuda ended with Scope CSS and so am I. It is an important feature and I helped build with some other folks this add-on that is one candidate for how we think it could be. I know there's other folks who've also been investing in this space and I think we're gonna wanna go through as a community and either merge those things or do an RFC process and figure out what are the best parts of each. But we really do think this is important to have in the framework, to have a good coherent story here. This one is, so this is pre-RFC so unlike a lot of the other features I've been talking about, this isn't something you should go committing to a cross-rehelled application unless you're really feeling adventurous, I guess. But you should definitely try it out and if you have the opportunity to use it a little to get feedback on it, that would be great. It's the feature that Yehuda pitched so I'm not gonna go into any more detail about the exact implementation or anything. Our add-on is, I think it really is showing the benefit already of how much easier it is to shift this kind of feature on the new infrastructure. So our add-on is invoiter only right now, that's the main caveat on it and it's because it's super easy to implement on invoiter. We got it pretty much working in a couple of days and yeah, there's definitely a follow-up work to get the polish and to solve the last issues around how you can figure the thing and all that but it's not a big project. When you compare it with how hard it is to do in the classic system, this kind of stuff, it's really no contest. We do also intend to close that gap and make this kind of add-on work in classic, again, to ease that adoption story, to give people locality, to let people adopt in their own rates. That work is ongoing right now in Ember Auto Import, which again, you should think of as our polyfill for Ember Auto Features in classic builds. The boundary today is that really, Ember Auto Import is very much like Ember Auto, it's doing it with a webpack-based build but it stays out of the core of your application because that has just got all the legacy behaviors it always had and Ember Auto Import was there originally for the third-party things that didn't need any of the Ember special stuff so we could just do a normal webpack build for them and we expanded that so that it also does V2 Ember add-ons because they're normal enough to just do that way and they benefit from those features and we're working right now on expanding it again so that you can opt into letting it control certain things that even mean your application and so CSS imports would be an example of that. Once you have that feature, implementing this kind of add-on on both classic and Ember Auto becomes a bit much, much easier. Other examples are things like I know Simon is working on Ember responsive image, making it be, it's already a super useful add-on, figuring out how it's gonna work in a V2 add-on world and still bring all that build-time capability also depends on this kind of a feature. So stuff to watch for that is already bringing these capabilities into your apps even if you haven't thought about or started to adopt Ember Auto, you're already beginning to get these features into your own applications. So with that, I'm wrapping up and Polaris is ambitious, it does sound ambitious and we've already built a lot of it. That's really the message I wanted you to take away is that we have invested very well in a bunch of powerful infrastructure and this is not the start of a project, this is the last third of a project. So together as a community, if the folks in this room are motivated to do this, we can absolutely do this with your help. Thank you.