 Hey, I'm Birkhoff. How's it going? My name is Chris, but you might know me better by my online handle, Xerox. And today, I'm here to talk about an exciting new feature that is just landing in the add-on ecosystem just now, and that I'm really looking forward to seeing, especially for how it's going to change how we write Ember applications. And that feature is template imports. So today, we'll go over what template imports are, if you haven't been following along in all the RFCs. We'll talk about what they look like in general, and we'll talk about how they work today. So let's get started. First off, what are template imports? Well, if you are an Ember developer today, you probably are familiar with how Ember resolves values in a template. It looks up the value based on its type and where it is in the file system. So if you are invoking a component, it'll look it up in the app slash components directory. And if you're invoking a helper, it'll look it up in the app slash helpers directory and so on. On the future, this is going to change. Rather than doing it based on directory structure, you're going to import the values explicitly using JavaScript syntax. And this is going to have a number of benefits. For instance, we're going to have better integration with editors and tooling overall. And we're going to have the ability to have a more flexible file layout. We'll still have strong conventions around our file layout. But you'll be able to have, for instance, components in the same directory as your routes. So if you have a component that's only used in your routes, that'll actually be able to be there with your route definitions, which will be really nice. It'll also work better with bundling and build tools, in particular, embroider, which is really going to be crucial for, you know, the future of bundling within Ember. And it also helps to simplify the internals and have better performance overall. So yeah, that's basically what template imports are. So next up, what do they look like? You can imagine, as soon as we started talking about this, there were a lot of different ideas about what it should look like in practice. Some folks thought that it could basically be the same as HBS files today, but just with the imports added to the top of them. Another idea was that we could do something like view or spelt, where we have a script portion for our JavaScript and a template portion for our templates. And then another idea was to use the existing HBS helper that you use to define templates in tests and just allow it to also refer to in scope values. Rather than committing to a high-level API right off the bat, we decided instead to ship a low-level API first. And that's where we're at today. Available in Ember 3.25 and up, you can use pre-compiled template to define a template that can then be associated with a component. And that can be provided a scope. It can be provided imported values and so on. This obviously isn't what we want people to be writing in their Ember applications. It's very verbose and requires a lot of understanding of low-level APIs. But it allows us to experiment and move forward as a community together, which is really what the goal was. We also created the Ember template imports add-on. The idea there is that rather than having a competition where it's all based on name recognition and so on, we would have a single place where we can share all of the different implementations of template imports and we can work together and share common infrastructure. So if you have an idea for template import syntaxes, please, PRs are welcome, open up an issue, we're happy to add more and happy for the help. Now finally, let's talk about how template imports work in practice today using the Ember template imports add-on. So far, we only have two different formats supported and they're kind of similar to each other. The first one is to use the HBS helper like you would in Ember tests today. And the second one is a new file format called GJS. In the first format in JavaScript files, we can see using the HBS helper, we can just define a template-only component like so. Export default HBS, hello world and there's your template-only component. In the GJS file, we use this syntax, this special syntax of defining a template using angle bracket template and we put our template inside of that and it automatically becomes the default export of that file because it's a top-level template. We can also see how we would use imported values within these templates. We can just import them and then reference them directly from the template itself. We don't have to do anything else beyond that. Another really cool feature about these formats is that it also allows us to actually define those values that we reference in the same file and this is one of the most exciting things about template imports to me. This means you can define a helper in the same file or a modifier or another component in the same file as your template-only component and that makes it much more flexible overall. It means that your template-only component can now have to arrive state. You can have private modifiers. You don't need to create a class in basically any case unless you possibly want to add some state. So let's see what that looks like. Here we add a track property to a component class and we define the template for that component class. In both cases, the template is defined within the class body. In the HBS-Bactic case, it is assigned to the static template property because it has to be valid JavaScript. And in the GJS case, we just define it in the body using our special syntax and it associates it based on it being inside the class body. So yeah, that's what these formats look like overall. And like I said before, we are definitely really excited about this and also open to new ideas, new PRs in general. The whole point of this period is to figure out what the details are, to figure out what the tooling looks like, what the build support looks like, what the ecosystem support looks like. And yeah, let's climb the mountain together. Alright, thank you.