A first look at Remix 3

Welcome to Syntaxuty. We're talking about Remix three. I went to Remix Jam, which was their conference in Toronto on Friday, and they gave us a CD, which is wild, with a demo on it.

And it was a fantastic conference. And, basically, what they did is they showed us what Remix three is going to be. So it's no more React. It's this brand new thing that they've thought up. It's full stack. We're gonna try to explain all of the little bits of it today here. We're not gonna go super in-depth. Like, Ryan and Michael had, I don't know, probably, like, four hours on stage, and they still didn't get to the entire framework. So I'm not gonna get into every little little bit of it, but I do hope to sort of explain to you the angle and the ideas behind it, and then we're gonna have Ryan and Michael on in a coming episode to to talk a little bit more about, like, why do they do things and and what are the what's the component model look like and and why x, y, z? You Node, all the all the nitty gritty. So just JS, like, like, a background, Remix was a full stack React framework.

And a lot of those features or almost all of those features have moved back into React router.

And and Remix, as you know, it is essentially gone.

And it's been reincarnated as a new full stack framework that has has nothing to do with React other than a lot of the ideas that they have are Yeah. Because they are fed up and frustrated with the state of the React ecosystem.

And and then a lot of Yeah. Yeah. And a lot has changed since React has has sort of been rolled out. So they kinda, like, peeled it back and said, like, what would a simple, dead Scott simple JavaScript full stack framework look like if we were to design it from scratch today? And I'm pretty excited about it. So

should we should we get into explaining how it all works? Let's do it because I'm curious. I'll tell you what. There's so much happening.

I like, I saw all the Remix stuff, and I'm sure Yep. I, like many other people, saw the remix stuff and were like, okay. That's happening.

And just, like, I I was unable to keep up with it. I have seen the syntax back and forth between, Ryan and the React team on Twitter. I have seen some of that conversation.

The syntax to me, like, first glance, feels a little over, but, like, yeah, I'm I'm interested to to learn why and, like, what it is and how it works and the reasoning behind it all because I am

totally out to lunch on this. That's that's what I'll I'll I'll encourage anybody listening. You probably people have written mean mean comments already in the replies anything. I didn't see. Of but, like, it's very Yarn. Like, I can't imagine them trying to explain everything and and the reasoning behind it in four hours, and then you just have one screenshot of, some code on the page, and and you get, like, a quick snap judgment. Oh, it looks like React with extra steps. You know? That's that's what I thought, but I didn't say it. I'll say it because I'm smart. So first of all, Remix three is uses the platform, meaning that all of the features of Remix are things that are built into the web platform.

Namely, events is probably the biggest one that we have here.

Signals, which we'll talk about that.

The back end, web streams, web requests, web response, fetch, Scott. All of the stuff is built with browser based, or not even browser Bos, JavaScript native features, which I am a huge fan of because I'm I'm a huge fan of vanilla, and I've written my own, like, little abstractions on top of vanilla in the past, but they've never been, like, amazing. It's usually just because I'm I'm building an app, and I I need a little bit of extra stuff on top.

But this is just, like, fully thought out. So Remix three, it's full stack. Like and and I mean, like, fully full stack.

It's got a whole component model built in. It has a router built in. They're building an entire, component library I like that. Which yeah. Something similar to, like like, a shad CSS or something where they have a whole designer on staff, so they're actually gonna look good. It's all based on HTML, CSS, obviously. They have a full server side to it as Wes. So mutations, partial rendering of different parts, a lot of handy helpers for things that you commonly want to do, like stream in files.

It's all LLM ready, which is something that I predicted, meaning that a lot of the features like, I'm just this morning, I was just going through. I had to literally take the demo off of the CD for me to use it. That's fine. A lot of the features are just, like, they're just it's just vanilla JavaScript, at the end of the day. So an LLM is very easily able to to generate code that looks like this because it's not a lot of custom the custom APIs they do have are are very thin layer on top that Yarn either make things a little bit easier. You Node? Like, every time you have to, like, send HTML as a response from, like, a web response. If you ever used a Cloudflare worker and you have to return HTML, you know, like, oh, this is annoying. I have to set the headers and everything like that. Like, just little convenience methods, or they do things so that they are fully type safe all the way

through. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.i0/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

My prediction. So, previously, my predictions were and I thought I would go through them. I would say that it's an LLM first. I I was predicting.

The reason I predicted that is because I thought that Shopify needed some sort of framework that you could boop boop boop into the box, and it would kick out like a a Shopify theme. I don't know that that it JS l l m first. It can write this code very well. I I was doing it this morning. I don't know that this was specifically made for Shopify, though. I think I was wrong on on that regard. I bet Shopify will use it, but I I had thought more that this is Shopify needs something.

And I think that this is more of a Shopify just JS cares about tech. So they're just funding these guys to build cool tech.

Yeah. It's all standard space. Nailed it there.

No build. I thought Ryan was talking about no build, like, the entire time. You know? Like, just use ESM. You don't need, like, live reloading. You don't need any of this blah blah blah.

That doesn't really seem to be the case. You can Node this stuff with no build. But but, really, like, I'll say it right now. There's there's TypeScript.

There's TSX for templating it out. There's not a custom

templating language that I thought they were gonna have. There's full server support for all of it. So you're very likely gonna need some sort of build tool, which I was relieved to see. Yeah. I I listen. Build tools don't bother me, so that doesn't crush me. Standards based is huge plus for me. I really refuse to use anything that's just abstracting the platform these days. Just just to refute I mean, like, like, meaningfully abstracting it because, like, that's I've resisted saying Svelte this whole time. But the thing that drove me to Svelte in the first place was that there is no there is a Svelte ecosystem, but it is the web ecosystem. I can drop in any DOM manipulation library and not have to worry about a wrapper for it. So Exactly.

A Scott of the frustration in the ecosystem right now is that React has a lot of custom APIs. And if you want to do anything in the React way, either install something or you have to do it you have to make some weird useEffect or or whatever. And I'm partially fine with that just because I understand how it works, but, also, it's very refreshing when when you don't have to know how some weird thing works because it's just just a web API. Right? And and Svelte has done a fantastic job at that.

So Yeah. And the browser API is not gonna shift on you. Like, if React comes out with a new version, you have to wait for, you know, a React form that works with React 19 whatever, with their new APIs. But, like, the web platform's not changing, folks. It's it's getting better, but, you know, it's not changing.

Mhmm. So let's talk about the component model. So the components in Remix three are written in TSX or or JSX. They don't have to be similar to how you don't have to use JSX in React, but Yeah.

Most people will will be doing that. And I was really happy to see that because that what that means is that, first of all, I'm comfortable in in JSX. I'm just gonna say JSX. And and when I say that, I mean, obviously, using TypeScript t s t s x. But then all of your tools that use TypeScript or or or TSX or JSX, they will just automatically work. So all of your linters, all of your formatters, all of your editor tools, Those things just work. AI is really good at at writing JSX at the end of the day, so there's no, like, new custom templating language that you're gonna need to learn.

State is simply just variables.

Get this.

If you if you wanna store some data in in a component, you simply just create some variables, and then those variables are then scoped to the component itself.

And then probably the biggest Do they update reactively? Sorry. Kerfuffle? That that's it. There's not reactive. That was the biggest kerfuffle.

So if you have a variable and you throw it into your JSX somewhere, that will not reactively update. You have to explicitly call this dot render when you want your component to rerender.

And the sort of the thinking behind that is that React gets into these weird loops of things, or you end up rerendering too often, or you have something way up higher in a a context tree, and then you wanna access that lower via context, and you have to rerender the whole tree all the way down.

So this gets around that by nothing is reactive. You simply just when you want to explicitly render, you call this dot render.

I wanna get your thoughts on that before we dive into a little bit more of that. What are your thoughts immediately?

My thoughts are that it would be nice if that was the API, but then there was also a reactive state primitive.

You just took my next point

out of the because that's how that's how Svelte five works. Again, sorry, folks. I'm gonna say it in this Node, but they have a reactive variable primitive. You get, fine grain reactivity where you want it. But then if you're just defining normal variables, they're just variables.

Like Yeah. Yeah. Yeah. So

to add reactivity to this like, I was sitting there watching this being like, I I don't know if I wanna have to call render every single time something changes, but there's nothing from stopping you from bringing in your own data store and and then just listening for changes on that data store and and passing it this dot render into the Yeah. Into the callback. So somebody already hooked it up to to x state.

Or if you're using any of your your local, local first packages, like like Deno sync or whatever Yeah. There's that's a reactive data store, and then you can you can listen for all of those things. So what is really cool about that is you don't have to use a specific state, and you don't have to use a specific package that adapts to this. Yeah. You bring your your own data store and then just pass it the render method.

Another question JS, when when render calls it, it's rerunning that entire function like React?

Yes. So, what I'm showing on screen right here is a well, it's it's it's only rerendering this component. I'm not sure if it will rerender it all the way down the tree,

but

But still, like, rerunning a function. Right? Scott, like, updating It's not. Yeah. It's not. It's not. That's that was a good question. So one of the things was I have this function here, and if I put some code at the top of the function, when that the whole thing rerenders, then all of that code at the top of the function also rerenders.

And then you get into this weird thing where if you add event listeners in there or something like that, the function doesn't return JSX. It returns a function Function. That returns JSX. So meaning that all of the code inside of your component that is above the return is simply just called once, when that initial thing is is run. And then the actual templating is is rerun when the render is called. So that's really nice Wes you don't have to do some weird use effect or or have, like, safe mode or or any of these oddities.

My most controversial web dev opinion, and I don't even know if this is controversial, is that, like, React developers or developers really buying into the entire function needs to rerun on every rerender is such a tremendous waste of time in terms of, like, how many foot guns or workarounds or things you have to consider just because the function reruns every time. You have to then consider all of the things that happened when that rerun like, if a variable changes, just update the stuff that affects that variable. Exactly. Can have side effects that watch for that variable to change, but, like, why you gotta rerun the whole thing? I never understood

why people were like, this is the way. You have to rerun the whole function. Like, that makes no sense to me. Yeah. And it's funny because, like, this is not a a weird API either. It's, like, the only difference is it's just you return a function instead of returning JSX. That's dope. Shout out to Remix. It just works. Yeah. So big fan of that. Now let's talk about probably the biggest idea here, and that is this, like, whole ESLint space architecture. So everything in in Remix is based on a an event, which is a JavaScript primitive, which is a browser primitive, being an an event target. So if you think about let let's peel this back. If you wanna think about a, like, a button or any HTML element in general, right, those elements, you can you can listen for events on. Right? You can grab a button. You can listen for a click on that event.

That button itself can also dispatch events, if they need to be custom. Right? You can you can fire off custom events from an event target, which which may or may not be an HTML element.

And if you have not done that before, I encourage you to look into dispatching custom events because it's really nice. What you can do is Yeah. You can make some sort of, like, data store.

And and when the data in that data store changes or or when anything happens to your application, you can simply just fire off events, and those events will bubble up to all of the parent elements. So in the past, I've I've made a hockey game. And whenever whenever anybody scores or whenever the score changes or whenever the players change, you can just fire off events saying, like, the score has been updated. The players have been changed. And then and then other parts of your applications that necessarily care about those events happening, you can simply listen for them. And if you don't want them to bubble up even further, you can stop propagation. You can use the event default, prevent default API.

So events in JavaScript and I know a lot of you know this, but events in JavaScript are not just the baked in ones. You can make your own custom events. Imagine that. And those events can also contain payloads of information about what happened. You know? Like, event dot current element of or whatever element you click, that's that's baked into to JavaScript. But you can also just

fire off a whole bunch of custom data with your event, and anybody who wants to listen to that can. Yeah. I love that. I love that. Custom events, man. Yeah. I, I've been building a handful of utilities myself and custom components and stuff I use on every project.

I don't know about you, but you collect these things that you just end up rewriting on every project. I'm, like, trying to formalize those into a package, for myself.

And, I did it first with my own, like, personal little CSS framework, and now I'm doing it with, like, standards based Svelte components. But custom events, totally underrated, man. I've been using a lot of custom events, and I love that stuff. So

that's just that's so far, all the events stuff I've been talking about, that's just JavaScript. Right? So the Remix stuff is is based on that. It's it's built on top of custom events. So what happens is, like, for example, I'm showing a fetch episode method that I've created.

This is a class called podcast player, and it extends event target. Right? This is this has nothing to do with Remix. This is simply a class that extends event target, and I've added a whole bunch of custom methods onto that. One of them being fetch episodes. And what that does is it hits the syntax API, it JSON. And then when that data comes back, we are simply adding that episode to state by saying this dot episodes equals Spread it. Yeah. I I don't even need to spread it. I don't even know why I'm spreading it. That's a reaction. Push it. I could just push it. That's how far I good. I've got my brain rotted by react state because I immediately went to spread it rather than just using

my mutation push. Mutating state is not a terrible thing, folks. No. It's easy.

You don't gotta create new state every time. Yeah. So

that state of this dot episodes has been been mutated. But because it is not reactive, then I have to go ahead and dispatch an event, which is a custom event that I've created called create list updated.

And that is a new Remix API called create event type, which, again, it's just a a thin layer on top of dispatch event that allows us to have fully typed, things. So that that way, when you're when you're firing off events or listening for them, you you know exactly what type of data you're getting. Because if you've ever used TypeScript and add event listener, you know there's all this BS around, is type of. You Node? You have to check if it's a specific type, and it's kind of a pain. So that's the firing off of it.

And then you can simply just go ahead in your UI. So the event target code, that's kind of like the logic and the the state of what is happening.

And then in the actual UI, the component part of of your Remix application, you simply just listen.

This is their own ad event listener syntax here where you can listen for, like, something on document or something on player. In my case, I'm listening for a player. And then you listen for specific events like a space Bos event or, in my case, I'm listening for a list updated event. So when the player fires off a list updated event, then I'm gonna go ahead and run this dot render. And what that will do is it will update this component. And, of course, you can you could do other things in this regard as well. Now you might be saying, okay. Well, how do I now surface this state or this custom functionality to the rest of my application? Right? Do you have to pass things down? Is it all is it down via props? Mhmm. You can simply just put it on context, and then you can access it by this dot context dot get.

And that will not retrigger sticking things in context ESLint awesome. I love it. But the the only downside is that it it sucks for for having to trigger those cascading re renders.

So in this case, you just go into a child component, which is just a function, grab the context, and then you can access all of the items that were on your your initial player.

You can listen for things in here as Wes, do exactly what you want. Yeah.

And is that type safe?

Yes. Yes. Oh, it's it's type safe all the way down.

I love that. And the reason why they do that is they have to use this the keyword this, which a lot of people groan that initially, myself included.

But if you here we go. This one here, remix dot handle. You pass it a generic of podcast player, and then you can say this dot context dot whatever, and you you have access to all of your types all the way down.

I love that. Man, context is because it it you have to be careful about renders in React. I think it it becomes an underrated API. But, in in in in Svelte, context is great for those reasons, but it's not type safe. So, like, you're, like, been casting when you put stuff into context in Svelte. Yeah. So, like, type safe context, I don't care about this keyword. Yeah. I don't care about that. I'll take that all day. Yeah.

Another thing is you can you can, like, wrap up or you can compose your interaction logic in their own events. So in this case, they built a drum machine as their their sample.

Yeah. And they just created a custom event called a tempo tap. And the logic of how does a tempo tap fire is is nice and tucked away into its own interaction. And all of the code as to how that happens is is tucked away into this thing called an interaction.

And and now you can just simply import that tempo tap event and and listen for it on each of them.

There's also a whole bunch. I'm not gonna go too much into it, but you can also compose, the events as well. So if you have a third party library that has some events, but you wanna add your own on top of that, you don't wanna overwrite them, but you wanna you wanna listen to both, but maybe you wanna stop propagation so it doesn't bubble up.

You can compose them together, which is really funny because Ryan and Michael were the guys who popularized the idea of high order functions of, like, composable React components that stuck together, and and here they are again doing it, but now with with with events.

Yeah. Yeah.

So that's, like, a a quick run. I know that wasn't quick, but that's a high level look at the whole ESLint space architecture. We'll get Ryan on here to maybe do a better job at explaining all of it, but I wanna move into some of the other parts of Remix as well. Yeah. Do it to it. Signals. So they they said Wes have signals, and everybody got really excited.

But they said not that kind of signals.

Okay.

Interesting. You have an async operation, most likely, the most common one is like like a fetch request.

Sometimes you want to, like like, abort, those specific things. So in in React, you might need to, like, have some sort of cleanup function or you might need to to cancel it or or use something else.

In Remix, they're all using this idea of abort signals, which is something that's built into the platform. So if a component, like, maybe fires off a fetch request and then it's unmounted, you can give that abort signal to Remix, and it will simply just call it and abort that fetch request if that's that's what you want. So, yeah, again, just another example of using the built in, methods that are built into the browser.

Benefits of standard. I wanted to to press on this a little bit of is that you can bring your own whatever you want. And and they're not the first one to do this, but, like, there isn't necessarily a Remix way of of doing most of this stuff. So you can bring a library in from it could be a web component. They showed many examples with web components. You can bring a library for for whatever you want, and it's just going to work. There's no weird oddities where, oh, I gotta stick this inside of a useEffect, and I gotta memoize it. And Right. I gotta I gotta have a ref for this thing. You Node? Like, if if you want to remember something, maybe you have to stick it in a ref so that when that function reruns, you're not overriding it. No. It's just it's just variables. It's variables and properties and events all the way down, which means bringing your own whatever. You wanna bring your own reactive data store to this. You wanna bring x date. You wanna you wanna Node up your own thing.

It seems to be that you'll be able to do a lot of this, bring your own whatever you want.

That's all I want. That's all I want out of any framework these days.

So that that's it. You know? We got all these tools. Bring your own. Yeah. Yeah. Don't make me learn a new concept that is, like,

specific knowledge. Right? You know? Talking real quick about CSS, CSS can be done any way you want. However, they do provide a built in CSS prop, that you can also do nested CSS inside of. So if you do wanna bring your own CSS or you wanna put your own CSS in via a prop like this because you're some sort of weirdo, I I quite honestly think that this is not a good way.

Yeah. I'm giving it a big old thumbs down. Yeah. You can, but it's there. And and I think the benefit of that, they said exactly that we didn't put this in because we think this is how you should do CSS.

We put this in because somebody should be able to ship a Remix component, and you should be able to import it, and it should just work. There shouldn't be some weird thing. Like, how many times have you ever tried to import a date picker in React, and you have to do this weird dance where you're trying to import their CSS because you don't use the same bundler as them? You Node, like, the OpenAI's example, they released this, like, SDK the other day, and they had an example with, like, a date picker.

And they simply just copy pasted all of the CSS into the example because there's no way to simply just import import the CSS and and ESLint it. This CSS, though, what they're doing is very similar to Svelte Wes they're they're just generating a class that

JS, like, a unique class, and then the CSS applies. I was I would I thought they would maybe use Scott CSS. It's not there yet. They're using the platform. Yeah. You think that's why? Yeah. That's why the Svelte team hasn't done it either. I I like their that like, when that is, like, fully available, it doesn't it doesn't exist in Firefox at all. So

Oh, yeah. Okay.

One day. This is, like, the eighth thing I've looked up this week that doesn't exist in Firefox. So

let's talk about the server. So all of that was simply just the, like, the front end UI rendering part of things, but this is a full stack framework.

So I think Ryan did a lot of work on, like, the actual front end side of things. And then Michael, I've been watching his GitHub, and he's been cranking out a lot of these, like, tiny little standards based packages.

And and this is what it was for. It was the server side is standard web Wes and web response, meaning that it's it's the same code that you would write in a Cloudflare worker. It's the same code that you would write in, like, a Deno JS.

It doesn't use any specific Node. Js APIs. So if you're using streams, you're not using Node streams. You're using web streams, which, of course, works in Node. It works in Dena. It works in BUN. It works in CloudFlare Workers. Right? It works across the board. So everything that they've they've done has sort of, like, gotten rid of any Node baggage that maybe you had, and now it's all using these brand new APIs or not brand new, but these new standard web APIs that that work across, all of the runtimes.

Very good.

The server itself has a bunch of, like, handy methods for common CRUD operations. So if you want to post to a specific endpoint or you want to get from one, all all of the stuff that you would probably expect from, like, a like, a Deno or something like that, but then it's also it also is connected to your your front end.

So, there's a bunch of handy things for working with file uploads as well. Like, it seems like it's a step further than than most stuff is going to be. You Node, we've always talked about, like, where's the Rails or where's the Laravel of JavaScript? Whereas, like, the the difference there being a lot of these JavaScript frameworks today will say, okay.

Here. You can here's your request.

Good luck.

And what a Laravel or what a Rails would would do is they would provide a whole bunch of helpers around this type of thing.

So this doesn't have anything to do with databases in terms of, like, a difference between, like, a Laravel or Rails, but it does provide a lot of, like, nice helpers for common things that you're gonna do, like simply just uploading files. If you have a file object in the browser and you send that file object from the browser to the server, on the server, it's a file object, and it's the exact same thing that you would you would be expect to have. And whatever you have to do to make it, like, multipart and all all of that fussing is is taken care of for you. So I'm pretty excited about all of those little cut edges, being taken care of.

One thing, frames.

So they they were teasing this idea of, like, iframes being the way to share Node, and I wasn't sure if they were were joking or not. And it it turns out they were kinda half joking. So in most of these frameworks, like, in React and React Vercel components, you have an asynchronous component that may take some amount of time. It's server rendered a synchronous component that maybe it needs to fetch some data and then render out and kick it out. Right? There's all this, like and Svelte has this now as well with their sync components where, you're not sure. Should I wait for this component, or or should I show, like, a a rendering screen? So it seems to be the same idea JS now in in Remix with this idea called frames.

A frame receives a URL, which is kinda nifty, meaning that every single, like, a like, a component in your application has a URL, and all of the data for that URL can be can be Scott.

All sorry. All of the Wes details can be sent over a URL.

Mhmm. And then a frame can be client rendered, can be server rendered. It can have a fallback. So if if it's taking a little while, you can show a loader screen or you can decide not to.

So that's kind of their take on doing this, like, asynchronous components that shouldn't necessarily hold up the the rest of the website. I love the name. Yes. It's a it's a great name. I still have to like, a lot of this code was, like, like, very early, very rough, and a lot of this, there's just not examples online just yet. So that's as well as I understand it right now. Yeah. Tooling. So I remember you mentioned it's JSX.

It's ESM all the way down. So, like, they didn't mention anything about tooling in the talk.

So I asked them after them. So, like, like like, what were you using there? Obviously, you you had some some bundler running to run this code.

And Michael said it's just ESM all the way down. And so anything that can output ESM can be used, as long as as long as it can bundle it output. So what I'm their demos are using Wes build, to just regenerate it. You're gonna need something on the server if you're running Node like ES build to actually compile the stuff on the fly. Like, you have a Wes, and and it's written in TypeScript, but you need to, like, bundle it Wes somebody sends a request. You're gonna need esbuild on the server, or you could do it you could do it at at build time as well if if it's like a static site. But very likely, you're gonna need something like BUN, Deno, or esbuild, and Node running on your server.

And very likely, I think everyone's just gonna be using Vite with all of this stuff. They didn't explicitly come out and say that probably because they wanna say, like, you can use whatever you want. If you wanna make your own weird Yeah. Bundler, splitter, loader, whatever, you can do that.

But this is just e s m at the end of the day, whatever tools you wanna use for that. And very likely, it's gonna be most people probably just be using Vite to kick out ESM at the end of the day. Yeah. Yeah. For sure. For show. For show. Routing, it's a code based router, so there's no more file system based routing.

They had some interesting talks from Shopify before in the morning, and Shopify was saying, like, we have thousands of routes, and we don't even know what our routes are. And, I think that was to sort of tee up this whole, like, this is a config based routing. It there the all of these routes are named, meaning that you would you give each one a Node, and you could each one could have, like, a get and a post and and whatever. So it's all of this stuff is very explicit, whereas, like, you probably saw some of the screenshots and were like, ugh.

You know? I don't like that. And there's there's no magic in any of this Yeah. Which I like a little bit of magic, but, also, I I like a little bit of explicitness.

I find it very easy to debug. Just being a couple hours in, it's easy to debug and to understand how everything works. Yeah. I'm caught between the world of loving a ton of magic and loving no magic. The constant

push and pull. Yes. For sure.

So questions or concerns? My only concern is, like, will I like the manual rerendering? And will I like the, like, data being stored on an object? Or will I, will I like something more, which my favorite right now is, like, what Svelte has Wes you just create a data store, import that thing when you want it, export it where you don't want. You may compute it. That's that's a very good approach to to data.

And will I like this more? It's it's yet to be seen. I'm not quite sure. Is the will the manually rerendering get annoying? Will people simply just put this dot render everywhere? Right. Because they don't know. They're tired at you. Like, I have I had a couple examples, and I clicked it, and nothing happened.

And I saw the data log in, and I was like, I'm missing this dot render somewhere.

You know? And, like, is it better to do something like Svelte Wes Svelte will just figure out which parts to to update for you, you know, Wes it's actually reactive

yet to be seen. Yeah? Will the community come up with a convention that ends up becoming the way. Like, remember with Deno, they were like, no package dot JSON. And then what we we ended up having, like, a depths dot t s or whatever it was that basically functioned as a a package dot JSON. Right? Like, where the community JS just like, okay. Well, we need one place to put this stuff. I do love the idea of, Deno file system based routing. I gotta be honest. I think there's a lot of truth to I don't know what all my routes are when you're looking at a massive folder structure. Right? Yeah. And when you have a routes file and you see it all there, I really liked that in React Router in the past. I did really like that Wes it felt very like, I had a total handle on everything. Because, yeah, you get nested directories, directory you know, you you can really lose track of that stuff, I think. And it also made, like, nested layouts really easy, not in Next. Js, obviously, but made nested layouts in any sane system. And, I I really like that approach. So

The Node thing I forgot to say is the routing is based on the new URL pattern API, which, again, this is a brand new the JavaScript now has a way to specify routes and, like, pattern match Yeah. Built in. It's called the URL pattern API.

And if you want to like like, back in the express days Wes you you wanted to, like, be like, oh, well, the dot PDF on the end is optional, or it could be dot PDF or dot CSS, and, the ID was is always gonna be there, and then it maybe the forward slash edit will be optional. You Node? Like, this very complex route URLs, I find myself Wes I hit those complex route URLs, I'm simply just adding multiple blank files in my directory structure Wes I simply just import the component and then export it right away.

So, we'll see. I I don't think we're using the URL pattern directly, Michael said, but all of the APIs are built on top of this, this spec, which, again, is a really good thing because it's built into the engine of these these runtimes.

And so it's gonna be fast as hell.

Hell, yeah. You know what, folks? We're in a new world of JavaScript frameworks. I can just imagine there's gonna be comments about LOL, another JavaScript framework, yada yada yada. Anytime we talk about anything new. But, man, let's face it. Like, it's it's like these things the the browser APIs have gotten better. We've learned a ton of lessons.

These things change all the time. Between this and Ripple and modern versions of other frameworks, we we are eating, in terms of, like, excellent framework options. Solid JS, like, there's there's a lot of great stuff. So, like, I I often get frustrated when people are like, React one. React is it. That's the only way to do things. It's like there's there are different approaches that have different strengths, and Yeah. You might, like who knows? Try it. You might be that bird who ate a cracker and liked it meme.

I I think, like like, one more thing is that, like, this stuff seems very easy.

And and I think that's their target audience JS, like, a lot of people who who think that React is just too hard, and but they also don't wanna have to relearn a new I'm saying they don't want it to relearn a new framework, but, I Wes you are kind of learning a new framework. Right. You've Scott you've gotta call render. That's a new framework to me. Yeah. Yeah. That's a different type of concept. It's it's a tricky thing, but, like, this maybe this will be the other, like, side of the coin is that, like, LLMs crank out React all day long. And in some regards, React has won because of that. So are they building something here that can both make us dummy developers happy, but also have the LLMs be able to understand and and crank it out to be seen, but I hope so.

Yeah. Yeah. We'll see.

Cool. Well, that's, that's really exciting, and and I'm I'm happy to hear that it is so standards focused. I I had full, faith that those guys would really put out something worth talking about, given their track record. So do you wanna get into sick picks, Wes? Alright. Sick pick. I'm going to sick pick my dishwasher.

My dishwasher died after twenty one years or 23 old or something like that.

It lasted a long, long time, and it finally, killed itself and and no longer Wes I can't believe it's gonna get banned. Unalived itself. Yes. Yeah. Oh, okay. Cut all that out. It finally died. So we bought pretty much the exact same one. This is a we got a Bosch 800 series, and this thing is freaking awesome, man. It just, like, scrubs the dishes so super well. There's three rows. It feels like somehow there's more space inside of it for all of the kids' stuff.

There's an app, which is a bit odd, but it's kinda nice because you can ask Google how long is left on the dishwasher cycle. That's pretty sick. Yeah. It's got the quick 60, which our old one didn't have. We love that feature where it's like, I just need to run, like, a quick load, and I don't I wanna wait around for two and a half hours. So I gotta be honest with that that, that that quick load feature is, like, really super handy. Like, there are there are so many times when your dishwasher does not need a full cycle. No. Like, straight up. Yeah. No. Very rarely. If you especially if you're, like, rinsing most of the crap off your plates as well. Right. 60 is plenty.

So I've been we were very happy with this thing. I I installed it the other day, and, it's it's better than the one that we had, the Bosch that lasted before. So if you Node a new dishwasher, spring for a Bosch. It's like a little probably, like, 1.5 times the cost of, like, a an LG or whatever. But, like, let me tell you. We got we have a Samsung, a brand new Samsung outer cottage, and I've had that thing pulled out probably five times. I replaced parts on it all the time. It's so frustrating. Ruined our cabinets at one point. It's just not worth getting a, like, a, what, saving $400 on a dishwasher and buying a very crappy one. It's not worth it.

Yeah. Shout out to Bosch.

Oh, Bosch. We bought a we bought a Bosch at our at our old house and was great. In our new house, the dishwasher, LG or something, right, LG or something, just started leaking all over the floor, and it Wes, like, ruined our hardwood. Wes actually has been to our house. We had to, like, resurface our entire floors.

And it was really sad when it was, like, during COVID and you couldn't get a Bosch dishwasher. It was, like, twelve months to get one or something, so we had to go with a different brand. But Did you get you got a Cove, though, didn't you? Those are amazing.

Yeah. But we paid for it. Oh, yeah. They are amazing.

And by all means, but it it was in an era where, like, we we didn't have a working dishwasher. I'd been washing them by hand for months.

And I always we had, you know, the two two little kids, and I was just like, you know what? We'll just shell out for the fancy dishwasher. It's the only one we can get right now. And, Yeah. I had my buddy do the same thing because he was just like, guys, I cannot find a dishwasher. What did you end up doing? It's like, we we wanted this fancy brand.

But it's also very nice dishwasher. No complaints there. But Bosch is where it's at. I'm gonna say pick a MoCA device.

I recently switched my Wi Fi routers, and I now have a wired the ability to have, like, a wired backhaul in my network. But I don't have Ethernet throughout my house, and, I got this Sunbeam MoCA, which they go up to 2.5, gigabit.

So I have one gigabit network. These go 2.5 gigabits and over coax.

And I just since I like, a nineteen nineties house, you best believe there's coax in every single room of this house. They're like, you need Yeah. You're gonna need TV in every room.

So we we have for our our mesh network, I now have a fully wired backhaul, via coax. And I was in the basement, which is, like, the furthest away, worst router.

And we have so many things, like, on that router that just like the Internet's always chugging.

And now I got 900 up and down from that router, just because the coax backhaul, no problem. So It works that well. Hey? I always thought, like,

Ethernet over, like, over power or Ethernet over coax. I'm like, like, yeah. I bet it's a pain. Node doesn't work as well, but you're you're getting full speeds.

2.5. Yeah. You know what? I did not the speeds were so good. I did not trust the speed test on the router. I was like, is this running, like, the full mesh mesh speed test, or is this running from this specific endpoint? And it was that endpoint. So, like, they didn't call it an endpoint, whatever they call it, whatever that router was. So, yeah, man. MoCA. Sick.

This stuff works.

And it's what was it? Like, a 100 and I'm looking at it right now. The one I got is a $130

for a oh, no. A $119

for a two pack. Oh, that's cheaper than a box of Ethernet, Corey. You would've spent more, running the wires.

Yeah.

Holy smokes. That's great.

I never thought that would work that well. Our house was wired with Scott five e. Yes. Our house is 20 years old, and it's it's cat five, which you can get 10 gigabits on short runs. And all of the runs in our house are short enough that they fall into that. So I was so happy because I didn't have to re fish.

Yeah. That's great.

Cool. Imagine doing it underground. Deno. Thanks. Alright. If you've got questions about Remix, put them in the boop boop boop down there. And when we have Ryan and Michael on, we'll be sure to ask them.

Please.

Nope.