Mitch Lloyd, I wanna talk to you about a library I just recently made.

It's not that technologically amazing, but I just kinda wanna put some code around an idea that I was having for a way to bring Ember to a server-rendered application. So first thing I'm gonna do is plug something. I made a set of training videos recently, and you can get those from Tilda's website, or you can buy them from my company's website, which is at teamgaslight.com slash training.

All right, so that's plugging. All right, so I work at a consultancy, and I don't get to use Ember as often as I would like, and that's because we always start every project and tell ourselves this is just a simple X, like a simple blog, a simple CMS, a simple e-commerce platform, and there's no way we're ever gonna want a JavaScript framework for this.

And then three weeks later, you know, we find that we're looking at different kinds of React patterns, and people are dropping in Angular, and the fact of the matter is is that everything seems simple at first, but nobody wants webpages mapped to crud actions anymore, like clients don't want it, and we don't even want to build it. So yeah, React and Angular will give people a quick win,

and refactoring to Ember seems really daunting. I think that's because people usually approach it thinking, you know, I want the entire Ember framework in my application. Let's do like a big vertical slice. I'm gonna serialize my models, make API endpoints. I'm gonna use Ember data, start using the router, and finally I'll get to the components, which is kind of the end goal if you think about it.

And along the way, you'll be like, oh man, how am I gonna get these translations over to the front end? Oh, I forgot I need the user data over there. How am I gonna bridge my URLs between the server part of the application and the client part of the application? And that refactor step is just too big, right? The developer had to make a paradigm shift from server rendered applications to client rendered applications, and that's like a big step.

And there's no progress until the very end. So you don't want to tell your client, well, you know, we're gonna work on this for a week, and when we come back, it'll be a little faster. This is not something we can tell them. So I'm kind of advocating an approach where we kind of think more top down and do a horizontal slice. Let's just grab the component layer first and use that in our refactoring.

And you could probably stay there pretty long. I mean, components are getting pretty awesome. You could extract data models from there. You could have services that are shared between those components, and you could probably get pretty far before you actually want to bring in other parts of the Ember ecosystem. So this is, okay, so this gives you like some wins really fast. Your server code doesn't need to change very much, and Ember's helping right away

instead of kind of slowing you down. So here's how this library works. You just make a element. You give it a data component attribute with the name of your component. You give it data adders, which is just JSON for that component to be rendered. And I dropped a Rails helper in the readme, which will tell you how to make a very small

Rails helper to do the same thing. So here is a quick, super quick demo. What I've got here is I just have like static content rendered in the index. And here's my data component called top level component. I'm passing it a title. If I actually enable, okay, so JavaScript is enabled now.

And if I refresh the page, you can see that I get all this glorious, I mean, I'm not actually a designer, although you might think so if I'm linking this. But you can expand like components work nested. You can use services. And it's just, it's like a good way to start. So people ask me how this works. It's really not anything weird at all.

Ember still initializes on the body. It just doesn't render anything. So you can just blank out your application HBS or just delete it. If I'm using jQuery, it goes finds those data component elements, renders those components using the container, and gives them their attributes and calls a pin two on it. And I've noticed this worked in like Ember 1.8.1. And last night I tried it out in Canary

and it continues to work. So that's good for now. We'll see if it's Glimmer compliant, but I'm not sure. And the good thing is all those components are connected to one Ember application, which is kind of nice over some other approaches that might use multiple Ember apps. So check it out. It's there GitHub and I'm too much on Twitter. Thank you very much. Thank you.