951: A first look at Remix 3

Scott and Wes dive into Remix 3, exploring how it embraces native web standards like Events, Signals, and Streams to become a truly full-stack framework. They unpack what “LLM-ready,” thin APIs, and a standards-based approach mean for the future of web development. Show Notes 00:00 Welcome to Syntax! 03:21 Uses the platform - native Events, Signals, Streams, Fetch 04:16 Remix 3, Fully Fullstack. 04:57 LLM‑ready + thin APIs 05:53 Brought to you by Sentry.io. 06:18 My previous predictions. 07:44 The value of ‘Standards Based’. 09:13 Component model - JSX/TSX; state = variables; call this.render() 11:56 Adding reactivity to Remix. 15:15 Event‑based architecture - custom events, EventTarget, interactions 20:52 Context & type‑safe access. 22:46 Composing interaction logic within events. 24:25 Signals - AbortSignal to cancel async ops 25:21 Benefits of standards - bring your own tools/libraries Michael Asnong X Post. 26:42 CSS - built‑in CSS prop; Svelte‑like scoping 28:34 Server - Web Request/Response, Web Streams across runtimes 31:23 Frames - async URL‑addressable components with fallbacks 33:07 Tooling - ESM; use Vite or esbuild 34:47 Routing - code‑based named routes 35:57 Questions/Concerns - manual rendering vs reactivity 38:47 URL Pattern API - modern, fast routing foundations 41:33 Sick Picks + Shameless Plugs. Sick Picks Scott: MoCA 2.5 Network Adapter Wes: Bosch Dishwasher Shameless Plugs Scott: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:01Wes Bos?

  Welcome to Syntax. Today, we're talking about Remix 3. 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 3 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 onstage, and they still didn't get to the entire framework.

• 0:45Wes Bos?

  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 what are the, what's the component model look like? And why XYZ? You know, all the, all the nitty gritty. So just as 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 Remix, as you know, it is essentially gone. And it's been reincarnated as a new full-stack framework

• 1:28Wes Bos?

  that has, has nothing to do with React, other than a lot of the ideas that they have are because they are fed up and frustrated with the state of the React ecosystem. And then a lot of, yeah, and a lot has changed since React has sort of been rolled out. So they kind of like peeled it back and said like, what would a simple, dead nut, 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?

• 2:09Scott Tolinski?

  Let's do it because I'm curious. I'll tell you what, there's so much happening. I like, I saw the remix stuff and I'm sure I like many other people saw the remix stuff and were like, okay, that's happening. And just like, 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 interested to learn why and like, what it is and how it works and the reasoning behind it all. Cause I am totally out to lunch on this.

• 2:49Wes Bos?

  That's, that's what I'll, I'll encourage anybody listening. You probably people have written mean, mean comments already in the replies.

• 2:56Scott Tolinski?

  I didn't say anything. I didn't say anything.

• 2:57Wes Bos?

  But like, it's very hard. 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 you get like a quick snap judgment. Ah, it looks like React with extra steps, you know?

• 3:17Scott Tolinski?

  That's, that's what I thought, but I didn't say it. I'll say it. Because I'm smarter than that.

• 3:21Wes Bos?

  So first of all, Remix 3 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 backend web streams, web requests, web response, fetch, state, all of this stuff is built with browser-based, or not even browser-based, JavaScript native features, which I am a huge fan of because I'm a huge fan of vanilla and I've written my own,

• 4:01Wes Bos?

  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 3, it's full stack, like, and I mean, like, fully full stack. It's got a whole component model built in, has a router built in. They're building an entire component library.

• 4:30Scott Tolinski?

  I like that.

• 4:31Wes Bos?

  Which, yeah, something similar to like, like a shad CN 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 well. 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.

• 5:11Scott Tolinski?

  That's fun.

• 5:12Wes Bos?

  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 APIs. And a lot of the custom APIs they do have are very thin layer on top that are either make things a little bit easier, you know, 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.

• 5:53Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry. At sentry.io/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 over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 6:18Wes Bos?

  My predictions. So previously, my predictions were, and I thought I would go through them. I would say that it's an LLM first. 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 Shopify theme. I don't know that that, it is LLM first. It can write this code very well. 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 as cares about tech. So they're just funding these guys to build cool tech.

• 7:04Wes Bos?

  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 do 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 going to have. There's full server support for all of it. So you're very likely going to need some sort of build tool, which I was relieved to see.

• 7:44Scott Tolinski?

  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 review, I mean, like, like meaningfully abstracting it. Cause like, that's,

• 8:03Scott Tolinski?

  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.

• 8:18Wes Bos?

  Exactly. A lot 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, you either install something or you have to do it. You have to make some weird use effect or, or whatever. And. I'm partially fine with that just because I understand how it works. But also, it's very refreshing when you don't have to know how some weird thing works. Because it's just, just a web API, right? And Svela has done a fantastic job at that.

• 8:53Scott Tolinski?

  Yeah, and the browser API is not going to 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 point whatever with their new APIs. But like, the web platform's not changing, folks. It's getting better, but you know, it's not changing.

• 9:13Wes Bos?

  So let's talk about the component model. So the components in Remix 3 are written in TSX or JSX. They don't have to be similar to how you don't have to use JSX in React. But most people will be doing that. And I was really happy to see that because what that means is that, first of all, I'm comfortable in JSX. I'm just going to say JSX. And when I say that, I mean, obviously, using TypeScript as TSX. But then all of your tools that use TypeScript or TSX or JSX, they will just automatically work. And so all of your linters, all of your formatters, all of your editor tools, those things just work.

• 9:56Wes Bos?

  AI is really good at writing JSX at the end of the day. So there's no like new custom templating language that you're going to need to learn. State is simply just variables. Get this. If you, if you want to 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

• 10:25Scott Tolinski?

  Do they update reactively?

• 10:26Wes Bos?

  Sorry. Curfuffle, that's it. There's not reactive. That was the biggest curfuffle. 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 re-render. And the sort of the thinking behind that is that React gets into these weird loops of things, or you end up re-rendering too often, or you have something way up higher in a context tree, and then you want to access that lower via context, and you have to re-render the whole tree all the way down. So this gets around that by,

• 11:08Wes Bos?

  nothing is reactive. You simply just, when you want to explicitly render, you call this dot render. I want to get your thoughts on that before we dive into a little bit more of that. What are your thoughts immediately?

• 11:23Scott Tolinski?

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

• 11:35Wes Bos?

  You just took my next point out of the-

• 11:38Scott Tolinski?

  Okay, because that's how Svelte 5 works. Again, sorry, folks, I'm gonna say it in this episode. But they have a reactive variable primitive. You get fine-grained reactivity where you want it. But then if you're just defining normal variables, they're just variables. Like, yeah, yeah.

• 11:56Wes Bos?

  So to add reactivity to this, like, I was sitting there watching this, being like, "I don't know if I want to have to call render every single time something changes." But there's nothing from stopping you from bringing in your own data store, and then just listening for changes on that data store and passing it, this dot render into the, into the callback. So somebody already hooked it up to X state. Or if you're using any of your, your local, local first packages, like Zero Sync or whatever, 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

• 12:38Wes Bos?

  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.

• 12:46Scott Tolinski?

  Yeah.

• 12:47Wes Bos?

  Just bring your own data store, and then just pass it the render method.

• 12:51Scott Tolinski?

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

• 12:57Wes Bos?

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

• 13:11Scott Tolinski?

  But still like rerunning a function, right?

• 13:13Wes Bos?

  Oh, no, it's not. 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 re-renders, then all of that code at the top of the function also re-renders. 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 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.

• 13:57Wes Bos?

  And then the actual templating is, is rerun when the render is called. So that's really nice where you don't have to do some weird use a factor or have like safe mode or, or any of this oddities.

• 14:12Scott Tolinski?

  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 re-render 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. You can have side effects that watch for that variable to change, but like. Why you gotta rerun the whole thing?

• 14:53Scott Tolinski?

  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.

• 15:01Wes Bos?

  Yeah. And it's funny because like, this is not a weird API either. It's like, the only difference is it's just you to return a function instead of returning JSX.

• 15:10Scott Tolinski?

  That's dope. Shout out to Remix.

• 15:12Wes Bos?

  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 event space architecture. So, everything in Remix is based on a, an event, which is a JavaScript primitive, which is a browser primitive, being an event target. So, if you think about, let's peel this back. If you want to think about a, like a button, or any HTML element in general, right? Those elements, you can, you can listen for events on them, right? You can grab a button, you can listen for a click on that event. And that button itself can also dispatch events if they need to be custom, right?

• 15:55Wes Bos?

  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, you can make some sort of like, data store. And, and when the data in that data store changes, 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

• 16:38Wes Bos?

  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.

• 17:05Scott Tolinski?

  Imagine that.

• 17:05Wes Bos?

  And those events can also contain payloads of information about what happened. You know, like event dot current element 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.

• 17:24Scott Tolinski?

  Yeah, I love that. I love that. Custom events, man.

• 17:27Wes Bos?

  Yeah.

• 17:28Scott Tolinski?

  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 a like standard space spell components. But custom events, totally underrated, man. I've been using a lot of custom events and I love that stuff.

• 17:56Wes Bos?

  So that's just that's so far all the event 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.

• 18:36Wes Bos?

  And then when that data comes back, we are simply adding that episode to state by saying this dot episodes equals.

• 18:45Scott Tolinski?

  Yeah.

• 18:46Wes Bos?

  I don't even need to spread it. I don't even know why I'm spreading it. That's a react.

• 18:49Scott Tolinski?

  You could just push it.

• 18:50Wes Bos?

  I could just push it. That's how far.

• 18:52Scott Tolinski?

  Push it real good.

• 18:53Wes Bos?

  I've got my brain rotted by React State because I immediately went to spread it rather than just using. My mutation push.

• 19:02Scott Tolinski?

  Mutating state is not a terrible thing, folks.

• 19:04Wes Bos?

  No.

• 19:05Scott Tolinski?

  It's easy. You don't gotta create new state every time. Yeah.

• 19:08Wes Bos?

  So that state of this dot episodes has 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 thin layer on top of dispatch event that allows us to have fully typed things. So that way, when you're, you're firing off events or listening for them, you, you know exactly what type of data you're getting. Cause if you've ever used TypeScript and add event listener, you know, there's all this BS around is type of, you know, you have to check if it's

• 19:53Wes Bos?

  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 state of what is happening. And then in the actual UI, the component part of your remix application, you simply just listen. This is their own add 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 spacebar event, or in my case,

• 20:35Wes Bos?

  I'm listening for a list updated event. So when the player fires off a list updated event, then I'm going to 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? You can simply just put it on context and then you can access it.

• 21:13Wes Bos?

  By this dot context dot get and that will not re-trigger it's sticking things in context is awesome. I love it, but the only downside is that 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 well. Do exactly what you want.

• 21:46Scott Tolinski?

  Yeah. And is that type safe?

• 21:50Wes Bos?

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

• 21:54Scott Tolinski?

  Love that.

• 21:54Wes Bos?

  And the reason why they do that is they have to use this the keyword this, which a lot of people groan at initially, myself included. But if you, here we go, this one here remix handle, you pass it a generic of podcast player. And then you can say this dot context, whatever, and you you have access to all of your types all the way down.

• 22:19Scott Tolinski?

  I love that. Man, context is because it you have to be careful about renders in React. I think it is becomes an underrated API, but in in in Svelte, context is great for those reasons, but it's not type safe. So like you're like then casting when you put stuff into context in Svelte. 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.

• 22:46Wes Bos?

  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. 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 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 going to go too much into it, but you can

• 23:30Wes Bos?

  also compose the events as well. So if you have a third party library that has some events, but you want to add your own on top of that, you don't want to overwrite them, but you want to, you want to listen to both, but maybe you want to stop propagation. So it doesn't bubble up.

• 23:47Wes Bos?

  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 here they are again, doing it, but now with with with events. Yeah, yeah. So that's like a quick run. I know that wasn't quick, but that's a high level look at the whole event space architecture. We'll get Ryan on here to maybe do a better job at explaining all of it. But I want to move into some of the other parts of remix as well. Yeah, do it to it. Signals. So they they said, we have signals and everybody got really excited. But they said, not that kind of signals.

• 24:33Wes Bos?

  So when you have in a sync 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.

• 25:19Wes Bos?

  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 I gotta stick this inside of a use effect and I gotta memoize it and

• 25:53Scott Tolinski?

  Right.

• 25:54Wes Bos?

  I gotta, I gotta have a ref for this thing, you know, 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 overwriting 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 want to bring your own reactive data store to this. You want to bring X state. You want to, you want to code 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.

• 26:26Scott Tolinski?

  Ah, that's all I want. That's all I want out of any framework these days. That's it. You know, we got all these tools.

• 26:34Wes Bos?

  Bring your own. Yeah.

• 26:35Scott Tolinski?

  Yeah. Don't make me learn a new concept that is like specific knowledge, right? You know?

• 26:42Wes Bos?

  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 want to bring your own CSS or you want to put your own CSS in via a prop like this, because you're some sort of weirdo, I quite honestly think that this is not a good way.

• 27:08Scott Tolinski?

  Yeah, I'm giving a big thumbs down. Yeah.

• 27:10Wes Bos?

  You can, but it's there. 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? 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 know, 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.

• 27:51Wes Bos?

  Because there's no way to simply just import, import the CSS and inline it. This CSS though, what they're doing is very similar to Svelte where they're, they're just generating a class. That is like a unique class and then the CSS applies. I was, I was, I thought they would maybe use Scope CSS.

• 28:11Scott Tolinski?

  It's not there yet.

• 28:12Wes Bos?

  They're using the platform. Yeah. You think that's why?

• 28:15Scott Tolinski?

  Yeah, that's why the Svelte team hasn't done it either. I like there that like when that is like fully available, it doesn't, it doesn't exist in Firefox at all. So.

• 28:23Wes Bos?

  Oh, yeah. Yeah. One day.

• 28:26Scott Tolinski?

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

• 28:33Wes Bos?

  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 standard space packages. And this is what it was for. It was the server side is standard web request 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 Hanno JS. It doesn't use any specific Node JS APIs. So if you're using streams, you're not using Node streams.

• 29:16Wes Bos?

  You're using web streams, which of course works in Node, it works in Dino, 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.

• 29:43Scott Tolinski?

  Very good.

• 29:44Wes Bos?

  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 of the stuff that you would probably expect from like a like a Hano 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 know, we've always talked about like, where's the rails or where's the Laravel of JavaScript?

• 30:24Wes Bos?

  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.

• 30:36Wes Bos?

  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 going to 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.

• 31:16Wes Bos?

  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 code. And I wasn't sure if they were, were joking or not. And it turns out they were kind of half joking, so. In most of these frameworks, like in React and React Server Components, you have an asynchronous component that may take some amount of time. It's server rendered asynchronous 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 async components where

• 32:00Wes Bos?

  you're not sure, should I wait for this component or should I show like a rendering screen? So it seems to be the same idea is now in Remix with this idea called Frames. A frame receives a URL, which is kind of nifty, meaning that every single, like a component in your application has a URL and all of the data for that URL can be, can be sent, all, sorry, all of the request details can be sent over a URL. And then a frame can be client rendered, can be server rendered, it can have a fallback. So if it's taking a little while, you can show a loader screen or you can decide not to.

• 32:41Wes Bos?

  So that's kind of their take on doing this asynchronous components that shouldn't necessarily hold up the rest of the website.

• 32:50Scott Tolinski?

  I love the name.

• 32:51Wes Bos?

  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.

• 33:06Scott Tolinski?

  Yeah.

• 33:07Wes Bos?

  Tooling. So I already 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, I'm so 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. What I'm, their demos are using ES Build to just regenerate it. You're gonna need something on the server.

• 33:48Wes Bos?

  If you're running Node like ES Build to actually compile the stuff on the fly. Like you have a request and it's written in TypeScript, but you need to like bundle it. When somebody sends a request, you're gonna need ES Build on the server. Or you could do it, you could do it at, at build time as well. If it's like a static site, but very likely you're gonna need something like Bun or Dino or ES Build and Node running on your server. And very likely, I think everyone's just gonna be using Veet 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 bundler, splitter, loader, whatever, you can do that.

• 34:32Wes Bos?

  But this is just ESM 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 Veet to kick out ESM at the end of the day.

• 34:45Scott Tolinski?

  Yeah, yeah, for sure, for sure, for sure.

• 34:48Wes Bos?

  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. There, the, all of these routes are named, meaning that you would, you give each one a name and you could, each one could have like a get and a post 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.

• 35:32Wes Bos?

  And there's, there's no magic in any of this. Which I like a little bit of magic, but also 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.

• 35:48Scott Tolinski?

  Yeah, I'm caught between the world of loving a ton of magic and loving no magic.

• 35:53Wes Bos?

  The constant.

• 35:55Scott Tolinski?

  Push and pull, yes, for sure.

• 35:59Wes Bos?

  So, questions or concerns? My only concern is like, will I like the manual re-rendering? 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, where 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 re-rendering get annoying? Will people simply just put this dot render everywhere?

• 36:39Scott Tolinski?

  Right.

• 36:39Wes Bos?

  Because they don't know.

• 36:41Scott Tolinski?

  They're tired of it, yeah.

• 36:42Wes Bos?

  Like I have, I had a couple of examples and I clicked it and nothing happened. And I saw the data log in and I was like, I'm missing a this dot render somewhere. You know, and like, is it better to do something like Svelte? Where Svelte will just figure out which parts to, to update for you, you know? Where it's actually reactive. Yet to be seen, yeah?

• 37:03Scott Tolinski?

  Will the community come up with a convention that ends up becoming the way? Like, remember with Dino, they were like, no package dot JSON? And then what we had, we ended up having like a depths dot TS or whatever it was, that basically functioned as a, a package dot JSON, right? Like, where the community is just like, okay, well, we need one place to put this stuff. I do love the idea of, uh, non-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?

• 37:37Wes Bos?

  Yeah.

• 37:37Scott Tolinski?

  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, where 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 NextJS obviously, but made nested layouts in any sane system. And, uh, I really liked that approach, so.

• 38:07Wes Bos?

  The one 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 built in. It's called the URL pattern API. And if you want to like, like back in the express days, when 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 CSV. And the ID was, is always going to be there. And then it maybe the forward slash edit will be optional. You know, like these very complex route URLs. I find myself when I hit those complex route URLs, I'm

• 38:50Wes Bos?

  simply just adding multiple blank files in my directory structure where I simply just import the component and then export it right away. So we'll see. 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 going to be fast as hell.

• 39:22Scott Tolinski?

  Hell yeah. You know what, folks? We're in a new world of JavaScript frameworks. I can just imagine there's going to 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 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 often get frustrated when people are like React one, React is it, that's the only way to do things.

• 40:03Scott Tolinski?

  It's like there's, there are different approaches that have different strengths. And you might like, who knows? Try it. You might be that bird who ate a cracker and liked it meme.

• 40:16Wes Bos?

  I think like, like one more thing is that like this stuff seems very easy. Um, and, and I think that's their target audiences, like a lot of people who, who think that react is just too hard. Um, and, but they also don't want to have to relearn a new, I'm saying they don't want it to relearn a new framework. But, uh, I guess you are kind of learning a new framework.

• 40:44Scott Tolinski?

  You gotta, if you gotta call render, that's a new framework to me.

• 40:46Wes Bos?

  Yeah, yeah.

• 40:47Scott Tolinski?

  That's a different type of concept.

• 40:49Wes Bos?

  It's, it's a tricky thing, but like this, maybe this will be, the other like side of the coin is that like, L L Ms crank out react all day long. And in some regards, react as one because of that. So are they building something here that can both make us dummy developers happy? But also have the L L Ms be able to understand and crank it out to be seen, but I hope so.

• 41:18Scott Tolinski?

  Yeah, yeah, we'll see. Um, cool. Well, that's, uh, that's really exciting and I'm, I'm happy to hear that it is so standards focused. I, I had full, uh, faith that those guys would really put out something.

• 41:30Wes Bos?

  Yes.

• 41:30Scott Tolinski?

  Talking about, uh, given their track record. So do you want to get into sick picks, Wes?

• 41:36Wes Bos?

  All right. Sick pick. I'm going to sick pick my dishwasher. Um, our dishwasher died after 21 years or 23 years old or something like that. It lasted a long, long time and it finally, uh, killed itself and it no longer was, I can't say that.

• 41:54Scott Tolinski?

  We're gonna get banned. Unalived itself. Yes.

• 41:56Wes Bos?

  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 kid's stuff. There's an app, which is a bit odd, but it's kind of nice because you can ask Google how long is left on the dishwasher cycle.

• 42:27Scott Tolinski?

  That's pretty sick, yeah.

• 42:28Wes Bos?

  It's got the quick 60, which our old one didn't have. We love that feature where it's like, ah, I just need to run like a quick load. And I don't, I want to wait around for two and a half hours. So.

• 42:38Scott Tolinski?

  I gotta be honest, Wes, that, that, uh, 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, like straight up. Yeah.

• 42:49Wes Bos?

  No, very rarely. If you, especially if you're like rinsing most of the crap off your plates as well.

• 42:54Scott Tolinski?

  Right.

• 42:54Wes Bos?

  60 is plenty. Um, so I've been, we were very happy with this thing. I installed it the other day. And, uh, it's, it's better than the one that we had, the Bosch that lasted before. So if you need a new dishwasher, spring for a Bosch. It's like a little, it 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 at our cottage. And I've had that thing pulled out probably five times. I've replaced parts on it all the time. It's so frustrating. Ruined our cabinets at one point. It's just not worth

• 43:34Wes Bos?

  getting a, like a, what, saving 400 bucks on a dishwasher and buying a very crappy one? It's not worth it.

• 43:41Scott Tolinski?

  Yeah. Shout out to Bosch. Uh,

• 43:44Wes Bos?

  Wes Bosch.

• 43:46Scott Tolinski?

  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 was 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 12 months to get one or something. So we had to go with a different brand, but.

• 44:15Wes Bos?

  You got a Cove though, didn't you? Those are amazing.

• 44:17Scott Tolinski?

  Yeah, but we paid for it.

• 44:19Wes Bos?

  Oh, yeah.

• 44:21Scott Tolinski?

  They are amazing and by all means, but it was at 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'm just like, you know what? We'll just shell out for the fancy dishwasher. It's the only one we can get right now.

• 44:39Wes Bos?

  Yeah.

• 44:39Scott Tolinski?

  Uh, 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, uh, we, we wanted this fancy brand.

• 44:49Scott Tolinski?

  But it's also very nice dishwasher. No complaints there, but Bosch is where it's at. Uh, I'm going to stick pick a Mocha device. I recently switched my wifi routers and I now have a wired, uh, the ability to have like a wired backhaul in my network, but I don't have Ethernet through on my house. And, uh, I got this Sunbeam Mocha, which they go up to 2.5, uh, gigabit. So I have one gigabit network. These go 2.5 gigabits and over coax. And I just, since I like a 1990s house, you best believe there's coax in every single room of this house.

• 45:29Wes Bos?

  They're like, you need, you're gonna need TV in every room.

• 45:32Scott Tolinski?

  Uh, so we, we have for our mesh network, I now have a fully wired backhaul, uh, via coax. And I was in the basement, which is like the furthest away worst router. Um, and we have so many things like, uh, on that router that just like the internet's always chugging. And now I got 900 up and down from that router, uh, just because the coax backhaul, no problem.

• 45:56Wes Bos?

  It works that well, hey? I always thought like Ethernet over like overpower or Ethernet over coax. I'm like, yeah, I bet it's a pain and doesn't work as well, but you're, you're getting full speeds.

• 46:09Scott Tolinski?

  2.5? Yeah. You know what? I did not try, 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. Uh, uh, whatever that router was. So yeah, man, uh, Mocha, sick. The, the stuff works.

• 46:31Wes Bos?

  And it's, what was it? Like a hundred and, I'm looking at it right now.

• 46:35Scott Tolinski?

  The one I got is 130 bucks for a, oh no, 119 bucks for a two pack.

• 46:43Wes Bos?

  Oh, that's cheaper than a box of Ethernet core. You would have spent more, um, running wires.

• 46:48Scott Tolinski?

  Yeah.

• 46:50Wes Bos?

  Holy smokes. That's great. I never thought that would work that well. Our house was wired with Cat 5E. Yes, our house is 20 years old and it's Cat 5, 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 want to have to refish. Oh, that's great.

• 47:16Scott Tolinski?

  Yeah, I imagine doing it underground. No, thanks.

• 47:19Wes Bos?

  All right. If you've got questions about remix, put them in the boop boop boodly boop down there. And when we have Ryan and Michael on, we will be sure to ask them.

• 47:29Scott Tolinski?

  Peace.