A First Look at Remix 3  ## Metadata - Author: [[YouTube]] - Full Title: A First Look at Remix 3 - Category: #articles - Document Tags: [[video-notes]] [[youtube]] - Summary: A first look at Remix 3 - URL: https://www.youtube.com/watch?v=_STrAAi8Ujg Welcome to Syntax. Today we're talkingabout Remix 3. I went to Remix Jam,which was their conference in Toronto onFriday, and they gave us a CD, which iswild, with a demo on it. Um, it wasa fantastic conference, and basicallywhat they did is they showed us whatRemix 3 is going to be. So, it's nolonger React. It's this brand new thingthat they've thought up. It's fullstack. We're going to try to explain allof the little bits of it today here. We're not going to go super in-depth.Like Ryan and Michael had, I don't know,probably like 4 hours on stage and theystill didn't get to the entireframework. So, I'm not going to get intoevery little bit of it, but I dohope to sort of explain to you the angleand the ideas behind it. Then we'regoing to have Ryan and Michael on in acoming episode to talk a little bitmore about why they do thingsand what the component model looks like,and why XYZ, you know, all thenitty-gritty. So just as a background,Remix was a full stack Reactframework and a lot of those features oralmost all of those features have moved. Back into React Router and Remix, asyou know, it has essentially gone. Um, andit's been reincarnated as a new fullstack framework that has nothing todo with React, other than a lot of theideas they have, which are because theyare fed up and frustrated with the stateof the React ecosystem. And that a lot>> Yeah.>> Yeah. And a lot has changed since Reacthas sort of been rolled out. So theykind of peeled it back and said,"What would a simpledead simple JavaScript full stackframework look like if we were to designit from scratch today? I'm prettyexcited about it. So should we, should weget into explaining how it all works? >> Let's do it because I'm curious. I'lltell you what, there's so muchhappening. I like, I saw all the Remixstuff, and I'm sure I like many otherpeople saw the Remix stuff and werelike, "Okay, that's happening." And justlike, I was unable to keep up with it.I have seen the syntax back and forthbetween Ryan and the React team onTwitter. I have seen some of thatconversation. The syntax, to me, likeat first glance, feels a little overwhelming. Like I'm interested to learn whyand what it is and how it works,and the reasoning behind it all because I amtotally out to lunch on this. That's what I'll encourage anybody listening;you probably people have written meancomments already in the replies.I don't say anything; honestly,but like it's very hard — like I can'timagine them trying to explaineverything and the reasoning behindit in four hours, and then you just haveone screenshot of some code on thepage,and you get a quick snap judgment;ah, it looks like React with extra steps,you know. That's what I thought, but Ididn't say it. I'll say that because I'msmarter. So first of all, Remix 3 uses theplatform, meaning that all of thefeatures of Remix are things that arebuilt into the web platform. Um, namely,events is probably the biggest one thatwe have here. Um, signals, which we'lltalk about, the backend, web streams,web request, web response, fetch,all of the stuff is built with. Browser-based, or not even browser-based, JavaScriptnative features, which I am a huge fan of,because I'm a huge fan of vanilla. I’ve written my own littleabstractions on top of vanilla in thepast, but they’ve never been likeamazing. It's usually just because I'mbuilding an app, and I need alittle bit of extra stuff on top. Um,but this is just fully thought out. So, Remix 3, it's full stack, andI mean like fully full stack. Um,it's got a whole component model builtin. It has a router built in. They're>> building an entire component library.Uh, I like that, which is something similar to likea Shad CN or something, where theyhave a whole designer on staff, sothey're actually going to look good. >> It's all based on HTML, CSS. Obviously,they have a full server side to it aswell. So, mutations, partial renderingof different parts. Um, a lot of handyhelpers for things that you commonlywant to do, like stream in files. It’sall LLM ready, which is something that Ipredicted, meaning that>> a lot of the features, like I'm justThis morning, I was just going through my files. I had to literally take the demo off ofthe CD for me to use it.>> A lot of the features are just like>> they're just vanillaJavaScript. At the end of the day,an LLM is very easily able togenerate code that looks like thisbecause there aren't a lot of custom APIs.A lot of the custom APIs they dohave are a very thin layer on top thateithermake things a little bit easier; youknow, like every time you have tosend HTML as a response from a webresponse. If you've ever used a Cloudflareworker and had to return HTML,you know, it's annoying. You haveto set the headers and everything likethat. Just little conveniencemethods, or they do things so that theyare fully type-safe all the way through. And if you want to see all of the errorsin your application, you'll want tocheck out Sentry at sentry.io/syntax.You don't want a production applicationout there without visibility in case something isblowing up, and you might not even knowit. So head on over to sentry.io/sax. Again, we've been using this tool for along time and it totally rolls. Allright.My predictions. So, previously, mypredictions were, and I thought I wouldgo through them. I would say that it'san LLM first. I was predicting thatthe reason I predicted that is because Ithought that Shopify needed some sort offramework that you could boop boop boopinto the box and it would kick out likea Shopify theme. I don’t know thatit is LLM first. It can write thiscode very well. I was doing it thismorning. Um, I don’t know that this wasspecifically made for Shopify though. I think I was wrong on that regard. Ibet Shopify will use it, but I hadthought more that this is Shopify needssomething. Um, and I think that this ismore of a Shopify just cares about tech,so they’re just funding these guys tobuild cool tech.Um, it’s all standard space. Nailed itthere. Um, no build. I thought Ryan wastalking about no build like the entiretime, you know, like just use ESM. Youdon’t need live reloading, youdon’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, butreally, like I'll say it right now,there's TypeScript, there's TSXfor templating it out.There's not acustom templating language that Ithought they were going to have.There's full server support for all of it. So,you're very likely gonna need some sortof build tool, which I was relieved tosee. Yeah, I listen, build tools don'tbother me, so that doesn't crush me.Standards based is a huge plus for me. Ireally refuse to use anythingthat's just abstracting the platformthese days. Just ref, I mean likemeaningfully abstracting it 'causethat'sthe thing that drove me tospelt in the first place, was that thereis a spelt ecosystem, but itis the web ecosystem. I can drop inany DOM manipulation library and nothave to worry about a wrapper for it. So,exactly. A lot of the frustration in theecosystem right now is that React has alot of custom APIs, and if you want to doAnything in the React way, you eitherinstall something or you have to do it. You have to make some weird use effector whatever. I'm partially finewith that just because I understand how itworks. But also it's very refreshingwhen you don't have to know howsome weird thing works because it’s justa web API, right? And Spell hasdone a fantastic job at that. So,yeah, and the browser API is not goingto shift on you like if React comes outwith a new version. You have to waitfor, you know, React form that workswith React 19, whatever, with their newAPIs. We're like, the web platform's notchanging, folks. It's gettingbetter, but you know, it's not changing. Mhm. So, let's talk about the componentmodel. The components in Remix 3 arewritten in TSX or JSX. They don'thave to be similar to how you don’t haveto use JSX in React. Butyeah,most people will be doing that. AndI was really happy to see that becausewhat that means is thatfirst of all, I'm comfortable in JSX. I say that, I mean obviously usingTypeScript as TSX, but then all of yourtools that use TypeScript or TSXor JSX, they will just automaticallywork. So all of your linters, all ofyour formatters, all of your editortools, those things just work. AI isreally good at writing JSX at the endof the day. So there’s no newcustom templating language that you’regoing to need to learn. State is simply just variables. Get this. If you want to storesome data in a component, you simplycreate some variables, and thenthose variables are then scoped to thecomponent itself. Um, and then probablythe biggest>> Do they update reactively? Sorry.>> Curuffle, that’s it. That is notreactive. That was the biggest curuffle.So if you have a variable and you throwit into your JSX somewhere, that willnot reactively update. You have toexplicitly call this when you want yourcomponent to rerender. Um, and the sortof the thinking behind that is thatReact gets into these weird loops ofthings, or you end up rerendering toooften. Higher in a context tree, you want to access that lower via contextand you have to re-render the whole treeall the way down. Um, this getsaround that by stating that nothing is reactive. Yousimply, when you want to explicitlyrender, you call this.I want to get your thoughts on thatbefore we dive into a little bit more ofthat. What are your thoughtsimmediately? >> My thoughts are that it would be nice ifthat was the API, but then there wasalso a reactive state primitive.Um,>> You just took my next point out of the>> because that's how spelled 5 works.Again, sorry folks, I'm going to say itin this episode, but they have areactive variable primitive. You get, uh,fine-grain reactivity where you want it,but if you're just defining normalvariables, they're just variables. Uh,like, yeah. >> Yeah. So to add reactivity to this, I was sitting there watching this and thinking,I don't know if I want to haveto call it render every single timesomething changes. But there's nothingstopping you from bringing in yourOwn data storeand then just listening for changeson that data store and passing itthis render into thecallback. So, somebody alreadyhooked it up to Xstate. Uh, or ifyou’re using any of your locallocal first packages like zero syncor whatever,there’s that reactive data store andthen you can listen for all ofthose things. So, what is really coolabout that isyou don’t have to use a specific stateand you don’t have to use a specificpackage that adapts to this. Yeah, youbring your own data store and then justpass it the render method. Another question is when rendercalls, it’s rerunning that entirefunction like React.Yes. So what I’m showing on screen righthere iswell, it’s only rerenderingthis component. I’m not sure if it willrerender it all the way down the tree,butstill like rerunning a function,right? Not likeNo, it’s not. It’s not. It’s not. That’sThat was a good question. So, one of thethings was>> I have this function here and if I putsome code at the top of the function,>> when that whole thing rerenders, thenall of that code at the top of thefunction also rerenders, and then you getinto this weird thing where if you addevent listeners in there or somethinglike that, the function doesn'treturn JSX; it returns a function thatreturns JSX. So, meaning that all of thecode inside of your component>> that is above the return is simply justcalled once when that initial thingis run, and then the actual templatingis rerun when the render is called. So that's really nice where you don'thave to do some weird use effect orhave like safe mode or any of theseoddities. My most controversial web developmentopinion, and I don't even know if thisis controversial, is that Reactdevelopers are really buyinginto the entire function needing to rerunon every rerender, which is such a tremendouswaste of time in terms of how manyfoot guns or workarounds or things youhave to consider just because thefunction reruns every time. Then consider all of the things thathappened when that rerun. Like if avariable changes, just update the stuffthat affects that variable.You can have side effects that watch forthat variable to change, but like whydo you have to rerun the whole thing? Inever understood why people were likethis is the way you have to rerun thewhole function. Like that makes no senseto me. Yeah. And it's funny because this is nota weird API either. It's like the onlydifference is you return afunction instead ofreturning JSX.That's dope.It just works. Yeah, so I'm a big fan of that. Now let's talk about probably thebiggest idea here, and that is thiswhole events-based architecture. Soeverything in Remix is based on anevent, which is a JavaScript primitive,which is a browser primitive, being anevent target. So if you think about, letlet's peel this back. If you want tothink about a button or any HTMLelement in general, right? Thoseelements, you can listen forevents on them, right? You can grab aWith a button, you can listen for a click onthat event. And that button itself canalso dispatch events if they need to be custom, right? You can fireoff custom events from an event targetwhich may or may not be an HTMLelement. And if you have not done thatbefore, I encourage you to look intodispatching custom events because it'sreally nice. So what you can do isyou can create some sort of datastore,and when the data in that data storechanges or when anything happens toyour application, you can simply justfire off events and those events willbubble up to all of the parent elements. In the past, I've made a hockeygame, and whenever anybodyscores or whenever the score changes orwhenever the players change, you can justfire off events saying that the scorehas been updated and the players have beenchanged, and then other parts ofyour application that careabout those events can simply listen for them.If you don't want them to bubble up even further, youcan stop propagation; you can use theprevent default API. Events in JavaScript, and I know a lot of you know this, but events inJavaScript are not just the baked-in ones.You can make your own custom events, andthose events can also contain payloadsof information about what happened. Youknow, like the event's current element orwhatever element you click. That's baked into JavaScript, but you canalso just fire off a whole bunch ofcustom data with your event, and anybodywho wants to listen to that can. >> Yeah, I love that. I love that, uh, customevents, man. I've been building ahandful of utilities myself and customcomponents and stuff I use on everyproject. I don't know about you, but youcollect these things that you just endup rewriting on every project. I'm liketrying to formalize those into a packagefor myself. >> And, uh, I did it first with my own littlepersonal CSS framework, and nowI’m doing it with standard spacecomponents, but custom events are totallyunderrated, man. I've been using a lotof custom events, and I love that stuff.So that's just so far all theevent stuff I've been talking about;that's just JavaScript, right? Remix stuff is based on that. It'sbuilt on top of custom events. Sowhat happens is, for example, I'mshowing a fetch episode method that I'vecreated. This is a class calledpodcast player, and it extends eventtarget. Right? This has nothingto do with Remix. This is simply a classthat extends event target. I'veadded a whole bunch of custom methodsonto that, one of them being fetchepisodes. What that does is it hitsthe syntax API in JSON. And then whenthat data comes back, we are simplyadding that episode to state by sayingthis equals>> spread it.>> This I don't even need to spread it. Idon't even know why I'm spreading it.That's a Reactism.>> Push it.>> I could just push it. That's how farI've got my brain rotted by React state,because I immediately went to spread itrather than just using>> my mutation push.>> Mutating state is not a terrible thing,folks. No,>> it's easy.>> You don't have to create new state every time. Time. Yeah.So, that state of this.ep episodes hasbeen mutated. But because it is notreactive, then I have to go ahead anddispatch an event, which is a customevent that I've created called createlist updated, and that is a new RemixAPI called create event type whichagain, it's just a thin layer on top ofdispatch event that allows us to havefully typed items. So that way,when you're firing off events orlistening for them, you know exactlywhat type of data you're getting. 'Cause ifyou've ever used TypeScript and addedevent listeners, you know there's all this BS aroundis type of, you know, you have tocheck if it's a specific type, and it'skind of a pain. So that's the firing offof it. Um, and then you can simply justgo ahead in your UI. So the event targetcode that's kind of like the logic andthe state of what is happening. Andthen in the actual UI, the componentpart of your Remix application, yousimply just listen. This is their ownaddEventListenersyntax here where you can listen forlike something on the document or something. On the player, in my case, I'm listening forthe player. And then you listen for specificevents like a spacebar event, or in mycase, I'm listening for a list updatedevent. So when the player fires off alist updated event, then I'm going to goahead and run this. And what that willdo is update this component. Andof course, you could do otherthings in this regard as well. Now, youmight be saying, "Okay, well, howdo I now surface this state or thiscustom functionality to the rest of myapplication?" Right? Do you have to passthings down? Is it all down viaprops? You can simply just put it oncontext, and then you can access itby this.context.get(). And that will not re-trigger.Sticking things in context is awesome;I love it. But the onlydownside is that it sucks forhaving to trigger those cascadingrerenders. So in this case, you justgo into a child component, which is justa function, grab the context, and thenyou can access all of the items thatwere on your initial player. You canlisten for things in here aswell. Do exactly what you want. Yeah. Um, and is that type safe?Yes. Yes. It's type safe allthe way down. Um, I love that. And thereason why they do that is they have touse the keyword this, which a lot ofpeople groaned at initially, myselfincluded. Um, but if you — here we go, thisone here, remix.andle, you pass it ageneric of podcast player, and then youcan say this.context; do whatever andyou have access to all of your typesall the way down. I love that, man. Context is because ityou have to be careful about rendersin React. I think it becomes anunderrated API. But um, in spelt,context is great for those reasons, butit's not type safe. So like you're likethen casting when you put stuff intocontext in spelt. So like type safe,context, I don't care about thiskeyword. I don't care about that. I'lltake that all day. Yeah. Um, anotherthing is you can wrap up orcompose your interaction logicin their own events. So in this case,they built a drum machine as theirsample. Um, and they just created acustom event called a tempo tap. And thelogic of how does a tempo tap fire. It is nice and tucked away into its owninteraction. And all of the code as tohow that happens is tucked away intothis thing called an interaction. Now you can simply import thattempo tap event and listen for it oneach of them. There’s also a whole bunchI’m not going to go too much into it,but you can also compose the eventsas well. So, if you have a third-partylibrary that has some events, but youwant to add your own on top of that, youdon’t want to overwrite them, but youwant to listen to both. Maybe you want to stop propagation so itdoesn't bubble up. You can composethem together, which is really funnybecause Ryan and Michael were the guyswho popularized the idea of higher-orderfunctions, like composable Reactcomponents that stuck together. Herethey are again doing it, but nowwith events. Yeah.So that’s a quick run. I knowthat wasn’t quick, but that’s ahigh-level look at the whole event spacearchitecture. We’ll get Ryan on here tomaybe do a better job at explaining allof it, but I want to move into some ofThe other parts of Remix as well. >> Yeah, do it to it.>> Signals. So, they said we havesignals, and everybody got reallyexcited. Um, but they said not that kindof signals. Uh, so when you have anasync operation, most likely the mostcommon one is like a fetch request.Sometimes you want to abortthose specific things. So in React,you might need to have some sort ofcleanup function, or you might need tocancel it, or use something else. InRemix, they're all using this idea ofabort signals, which is something that'sbuilt into the platform. So if acomponent fires off a fetchrequest and then it's unmounted, youcan give that abort signal to Remix, andit will simply call it and abortthat fetch request if that's whatyou want. So yeah, again, just anotherexample of using the built-in methodsthat are built into the browser. The benefits of standard. I wanted topress on this a little bit — is thatyou can bring your own whatever you want,and they're not the first one to dothis, but there isn't necessarily aRemix way of doing most of this. Stuff. So you can bring a library infrom, it could be a web component. Theyshowed many examples with webcomponents. You can bring a library forwhatever you want, and it's justgoing to work. There's no weird odditieswhere, oh, I gotta stick this inside of auseEffect, and I gotta memoize it.Right?I gotta have a ref for thisthing, you know? Like if you want toremember something,maybe you have to stick it in a ref sothat when that function reruns, you'renot overwriting it. No, it's just variables. It's variables andproperties and events all the way down,which means bringing your own whateveryou want to bring your own reactive datastore to this. You want to bring XATE;you want to code up your ownthing. It seems to be that you'll beable to do a lot of this. Bring your ownwhatever you want. Ah, that's all Iwant. That's all I want out of anyframework these days. That's it. Youknow, we got all these tools.Bring your own. Yeah.Yeah. Don't make me learn a new conceptthat is likeSpecific knowledge, right? You know,talking real quick about CSS. The CSS can be done any way you want.However, they do provide a built-in CSSprop that you can also do nested CSSinside of. So, if you do want to bringyour own CSS or you want to put your ownCSS in via a prop like this becauseyou’re some sort of weirdo, I quitehonestly think that this is not a goodway.Yeah, I’m giving a big old thumbs down. Yeah,you can, but it’s there and Ithink the benefit of that, they said,exactly that we didn’t put this inbecause we think this is how you shoulddo CSS. We put this in because somebodyshould be able to ship a remix componentand you should be able to import it andit should just work. There shouldn’t besome weird thing like how many timeshave you ever tried to import a datepicker in React, and you have to do thisweird dance where you’re trying toimport their CSS because you don’t usethe same bundler as them. You know, likeOpenAI’s example, they released thisSDK the other day, and they had anexample with a date picker and theySimply just copy-pasted all of the CSSinto the example because there was noway to simply import the CSSand inline it. This CSS, though,what they're doing is very similar to Spelt,where they're just generating aclassthat is like a unique class, and then theCSS applies. I thought theywould maybe use scoped CSS. >> It's not there yet.>> They're using the platform. Yeah. Youthink that's why?>> Yeah. That's why the Spelt team hasn'tdone it either. I like that when it is fully available, itdoesn’t exist in Firefox atall. So>> Oh, yeah. Okay.>> One day.>> This is like the eighth thing I’velooked up this week that doesn’t existin Firefox. So,>> Uh, let’s talk about the server. So allof that was simply just the front-end UI rendering part of things,but this is a full-stack framework. Um,so I think Ryan did a lot of work onthe actual front-end side ofthings. And then Michael, I’ve beenWatching his GitHub, he's beencranking out a lot of these tinylittle standard packages, and thisis what it was for. It was the serverside — standard web request and webresponse. Meaning that it's thesame code that you would write in aCloudflare worker. It's the same codethat you would write in a HANAJS. It doesn't use any specific Node.jsAPIs. So if you're using streams, you'renot using Node Streams; you're using webstreams, which of course works in Node,it works in Deno, it works in Bun, and itworks in Cloudflare workers, right? It worksacross the board. Everything thatthey've done has sort of gotten rid of any Nodebaggage that maybe you had, and now it's all usingthese brand new APIs, or not brand new,but these new standard web APIs thatwork across all of the runtimes. Very good.The server itself has a bunch of handy methods for common CRUDoperations. So if you want to post to aspecific endpoint or you want to getfrom one, all of the stuff thatyou would probably expect from aHANA or something like that, butThen it's also connected toyour front end. So there are abunch of handy things for working withfile uploads as well. It seems likeit's a step further than most stuffis going to be. You know, we've alwaystalked about where's the Rails orwhere's the Laravel of JavaScript,whereas the difference thereis that a lot of these JavaScript frameworks today will say, "Okay, here you can, here'syour request." Good luck. Um, what a Laravel or whata Rails would do is provide a whole bunch of helpers aroundthis type of thing. So this doesn’thave anything to do with databases interms of a difference between Laravel and Rails, but it does providea lot of nice helpers for commonthings that you're going to do, likesimply just uploading files. If you havea file object in the browser and yousend that file object from the browser,on the server it's a fileobject and it's the exact same thingthat you would expect tohave, and whatever you have to do to makeit multi-part and all of that. Fussing is taken care of for you. SoI'm pretty excited about all of thoselittle cut edges being taken care of. One thing frames.They were teasing this idea oflike I frames being the way to sharecode, and I wasn't sure if they were joking or not, and it turns out theywere kind of half joking. So in most ofthese frameworks, like in React andReact server components, you have anasynchronous component that may takesome amount of time. It's serverrendered, a synchronous component thatmaybe needs to fetch some data andthen render out and kick it out, right?There's all this, and spelt has thisnow as well with their sync components,where you're not sure should I waitfor this component or should I showlike a rendering screen. So it seemsto be the same idea now in Remixwith this idea called frames. A framereceives a URL, which is kind ofnifty. Meaning that every singlecomponent in yourapplication has a URL, and all of thedata for that URL can be sent. It can be sent over a URL,and then a frame can be client-rendered.It can be server-rendered, it can have afallback. So if it's taking a littlewhile, you can show a loader screen oryou can decide not to. That’s kind oftheirtake on doing this like asynchronouscomponents that shouldn’t necessarilyhold up the rest of the website. I love the name.Yes, it’s a great name. I stillhave to note that a lot of this code wasvery early, very rough, and there are a lotof examples that are just not available onlinejust yet. So that’s my understanding right now. Yeah.Tooling. So I already mentioned it’sJSX. Um, it’s ESM all the way down. Sothey didn’t mention anything abouttooling in the talk. So I asked himafterward. Like, what were youusing there? Obviously, you had somebundler running to execute this code.Um, and Michael said it’s just ESM allthe way down. So, anything that canoutput ESM can be used, as long as it canbundle the output.What I’m saying is their demos are using ES build. Um, to just regenerate it, you're goingto need something on the server. Ifyou're running Node, like ESB build, toactually compile this stuff on the fly,like you have a request and it'swritten in TypeScript, but you need tobundle it when somebody sends arequest, you're going to need ESB buildon the server, or you could do it at build time as well ifit's like a static site. But verylikely you’re going to need somethinglike bun, Dino, or ESB build and Noderunning on your server. And very likelyI think everyone’s just going to be using VIT with all of this stuff. Theydidn’t explicitly come out and say thatprobably because they want to say, like,you can use whatever you want. If youwant to make your own weirdbundler, splitter, loader, whatever, youcan do that. Um, but this is just ESM atthe end of the day. Whatever tools youwant to use for that. And very likelyit's going to be most people probablyjust be using V to kick out ESM at theend of the day. Yeah. Yeah. For sure. For sure.For sure.Routing. Um, it’s a code-based router, soThere's no more file system-basedrouting. Umthey had some interesting talks fromShopify before in the morning, andShopify was saying, "We havethousands of routes, and we don’t evenknow what our routes are." And um, I thinkthat was to sort of tee up this wholelikethis is a config-based routing. All of theseroutes are named,meaning that you would give each onea name, and each one could havelike a GET and a POST and whatever. So, all of this stuff isvery explicit, whereas like you probablysaw some of the screenshots and werelike, "You know, I don’t like that." Andthere's no magic in any of this.Um, which I like, a little bit of magic,but also I like a little bit ofexplicitness. I find it very easy to debug.Just being a couple of hours in, it's easyto debug and to understand howeverything works. Yeah, I'm caughtbetween the world of loving a ton ofmagic and loving no magic. The constantpush and pull. Yes, for sure.Um, so questions or concerns? My onlyConcern is like, will I like the manualrerendering, and will I like the data being stored on an object, or will Ilike something more? Myfavorite right now is what Speltdoes, where you just create a data store,import that thing when you want it,and export it when you don’t want it. You makecomputed. That’s a very goodapproach to data, and will I likethis more? It’s yet to be seen. I’mnot quite sure. Will the manualrerendering get annoying? Will peoplesimply just put this render everywhere? >> Right?>> Because they don’t know, they’re tired. Yeah, I like, I had a coupleexamples. I clicked it, and nothinghappened. I saw the data log in, and Iwas like, I’m missing this rendersomewhere, you know? And like, is itbetter to do something like Spelt, whereSpelt will just figure out which partsto update for you, you know? Whereit’s actually reactive. >> Yet to be seen. Yeah.>> Will the community come up with aconvention that ends up becoming theway? Like remember with Dino, they werelike, no package.json, and then what weHad we ended up having a deps.ts orwhatever it was that basicallyfunctioned as a package.json, right? Like where the community is just like,"Okay, well, we need one place to put thisstuff." I do love the idea of non-filesystem-based routing. I gotta be honest. I think there's a lot of truth to it; Idon't know what all my routes are whenyou're looking at a massive folderstructure, right? Yeah. And when youhave a routes file and you see it allthere, I really liked that in ReactRouter in the past. I did really likethat where it felt very much like I had atotal handle on everything because, yeah,you get nested directories; you know,you can really lose track ofthat stuff. I think it also made nestedlayouts really easy—not in X.JS,obviously—but it made nested layouts in anysane system, and I really like thatapproach. So the one thing I forgotto say is that the routing is based on thenew URL pattern API, which again, this isa brand new way JavaScript now has tospecify routes and pattern matchbuilt-in. It's called the URL patternAPI. And if you want to, like backTo be like, "Oh well, the PDF at theend is optional," or it could be PDF orCSV. The ID is always going tobe there, and maybe the for/editwill be optional. You know, like thesevery complexroute URLs. I find myself when I hitthose complex route URLs, I’m simplyjust adding multipleblank files in my directory structurewhere I simply import the componentand then export it right away. So, yeah, we’ll see. I don’t thinkwe’re using the URL pattern directly,Michael said, but all of the APIs arebuilt on top of this spec, whichagain is a really good thing becauseit’s built into the engine of theseruntimes, and so it’s going to befast as hell. Hell yeah. You know what,folks? We’re in a new world ofJavaScript frameworks. I can justimagine there are going to be commentsabout "LOL, another JavaScript framework,"yada yada yada, anytime we talk aboutanything new. But man, let’s face it,it’s like these things—the browser APIshave gotten better. We’velearned a ton of lessons. These thingschange all the time between this>> And Ripple and modern versions of otherframeworks. We are eating, uh, in termsof excellent framework options. SolidJS, like>> there's a lot of great stuff. Solike I often get frustrated whenpeople say that React isthe only way to do things.It's like there are differentapproaches that have different strengths,and you might like>> who knows? Try it; you might be that birdwho ate a cracker and liked it meme. Um.>> I think like one more thing isthat this stuff seemsvery easy. Um, and I think that'stheir target audience is a lot ofpeople who think that React is justtoo hard. Um, but they also don'twant to have to relearn a new framework.They don't want to relearn a newframework, but I guess you are kind of learning a new framework.>> You got to call render; that'sa new framework to me.>> Yeah. Yeah.>> That's a different type of concept.>> It's a tricky thing. But like thismaybe this will be the other like flipside of the coin is that like LLMs crankOutreact all day long. In someregards, React has won because of that. So, are they building something here thatcan make both developers happybut also allow the LLMs tounderstand and crank it out? To be seen,I hope so. >> Yeah. Yeah. We'll see. Um, cool. Well,that's really exciting, and I'mhappy to hear that it is sostandards-focused. I had full faiththat those guys would really put outsomething worth talking about, giventheir track record. So, do you want toget into sick picks, Wes? >> All right. Sick pick. I'm going to pick my dishwasher. Um, our dishwasher>> died after 21 or 23 years orsomething like that. It lasted a longtime and it finally diedon its own.I couldn’t get it to work anymore.>> Unlived itself. Yes.>> Yeah. Okay, cut all that out. Itfinally died. So, we bought pretty muchthe exact same one. This is a Bosch 800 series,and this thing isfreaking awesome, man. It just scrubs the dishes so well.There are three rows. It feels like somehowThere's more space inside of it for allof the kids' stuff. There's an app, whichis a bit odd, but it's kind of nicebecause you can ask Google how long isleft on the dishwasher cycle. >> That's pretty sick.>> Um, it's got the quick 60, which our oldone didn't have. We love that featurewhere it's like, uh, I just need to runlike a quick load and I don't want to wait around for two and a halfhours. So, I got to be honest, Wes, thatthat, uh, that quick load feature isreally super handy. There areso many times when yourdishwasher does not need a full cyclelike straight up. Yeah. >> No, very rarely if you'relike rinsing most of the crap offyour plates as well,>> right?>> 60 is plenty. Um, so I've been very happy with this thing.I installed it the other day and, uh, it'sbetter than the one that we had, theBosch that lasted before. So if you needa new dishwasher,spring for a Bosch. It's like a littleprobably like 1.5 times the cost ofan LG or whatever, but like letLet me tell you, we gota Samsung, a brand new Samsung atour cottage, and I've had that thingpulled out probably five times. I'vereplaced parts on it all the time. It'sso frustrating. It ruined our cabinets atone point. It's just not worthsaving 400 buckson a dishwasher and buying a very crappyone. It's not worth it. Yeah. Shout out to Bosch.We bought a Bosch at our old house, and it was great. In our newhouse, the dishwasher, LG or something,just startedleaking all over the floor, and it waslike it ruined our hardwood. Wes actuallyhas been to our house. We had to likeresurface our entire floors. And it was really sad when, during COVID,you couldn't get a Boschdishwasher. It was like 12 months to getone or something. So, we had to go witha different brand. But, um,you got a Cove though, didn'tyou? Those are amazing. Yeah, but we paid for it.Oh, yeah.They are amazing. And by all means,it was an era where weI didn't have a working dishwasher. I hadbeen washing them by hand for months, andwe had, you know, the two little kids, and I was just like, youknow what? We'll just shell out for thefancy dishwasher. It's the only one wecan get right now. And, uh, yeah, I had mybuddy do the same thing because he wasjust like, "Guys, I cannot find adishwasher. What did you end up doing?"It's like, "Uh, we wanted this fancybrand." Um,but it's also a very nice dishwasher. Nocomplaints there, but Bosch is whereit's at. Uh, I'm going to pick aMocha device. I recently switched myWi-Fi routers, and I now have theability to have a wired backhaulin my network, but I don’t have Ethernetthroughout my house. And, uh, I got thisSunbeam Mocha, which goes up to 2.5gigabits. So I have a 1 GB network. These go 2.5 GBs over coax, and Ijust, since it's like a 1990s house, you bestbelieve there's coax in every singleroom of this house. They're like, youneedyou’re going to need TV in every room.Uh, so we have, for our mesh network, Inow have a fully wired backhaulI was using coax and was in the basement, which isthe furthest away from the worst router. Umwe have so many devices onthat router that theinternet is always chugging. And now Ihave 900 up and down from that router,just because of the coax backhaul. Noproblems. Soit works that well. Hey, I alwaysthought Ethernet overpower or Ethernet over coax would bea pain and wouldn't workas well. But I’m getting fullspeeds, 2.5. Yeah. You know what? I didnot trust the speeds were so good. I didnot trust the speed test on the router. I was wondering if it was running thefull mesh speed test or if it wasrunning from a specific endpoint.It was that endpoint. So theydidn’t call it an endpoint, whateverthey called it. Um, whatever that routerwas. So, yeah, man. Um, Mocha is sick. Thestuff works. And what was it like? I’m lookingat it right now.The one I got is 130 bucks for a... Oh, no.119 bucks for a two-pack. Oh, that’scheaper than a box of Ethernet cabling. Youwould have spent more on running wires. Yeah.Holy smokes, that's great.I never thought that would work thatwell. Our house waswired with Cat 5E. Yes. Our house is 20 years old andit's Cat 5, which you can get 10gigabits on short runs, and all of theruns in our house are short enough thatthey fall into that. So, I was so happybecause I didn't have to fish. That's great.Cool. Imagine doing underground. Nothanks.All right. If you've got questions aboutremix, put them in the booply boop downthere, and when we have Ryan and Michaelon, we will be sure to ask them. Peace., A First Look at Remix 3, YouTube, 01k952xvy3q925w23204bgsj6y.