Let's talk about the future of Remix and react-router

00:00 I took a nap and I woke up and it turns out that Remix woke up as well. Well, let's talk about it. So a few days ago, they published this Wake Up Remix article. As you can see the disc in the background it's time for Remix version 3 to wake up and it's going to be a completely different thing than what Remix version 2 was and I'm kind of here to demystify it and go through it with you and talk about it. So at React Conf last summer they kind of announced that Remix is taking a nap, that they're going to merge Remix into ReactRouter version 7.

00:34 If you don't know why it's because Remix got to a point where it was basically a glorified re-export of ReactRouter so I decided to move everything back into it so both ReactRouter version 6 and 5 users had a way to migrate to Remix kind of apps and also to allow them to do a completely different thing with remix Which we will see through this article and ever since then they kept it really under the wraps on what they're working on and this is the first thing we're hearing about Remix in like half a year so if you don't know why we are excited that's completely why. So if you're wondering hey what does this mean for React Router is it going to get discontinued. Is anybody going to work on it? What's the future looking like? Well, you don't have to worry.

01:23 This is completely unrelated from React router and React router itself has some exciting news where it's going to have an open governance model and the react router core team is going to be governing a committee that's going to decide what features from the community are going to be added and merged into react router. From what I understood, they had a severe bottleneck with the current approach where they would have to get approval from Ryan and MJ and those guys are kind of busy So I'm guessing that's the reason why they're doing this and how it's gonna work is pretty much like TC39 it's gonna have five phases and If it gets accepted and implemented and everything and goes into phase five it gets added to react router Otherwise it gets rejected and I think this is kind of one of the low-key coolest things about this article because react router is going to be better than ever. The future for it is really exciting but that's not the topic of today's video is it now? Well what is? Remixes and if we look at the new path here this is the meat of the article so I'm not gonna read through the new path here but rather I'm gonna briefly explain to you what they aim to do so as I said over the past few years they wanted to build something completely different and disruptive but their biggest issue was that they didn't want to break everything for their existing user bases so because they decided to move Remix into React Router now React Router is a stable story that's going to grow over the years now they have the freedom to basically do anything they want with remix version 3 and forge a new path forward whatever that looks like and that is what they intend to do and how they're gonna do that Is they're gonna build their own framework that's going to probably have everything built in Much like Laravel and how they're gonna do that is they're gonna move away from react So that's the first big shocker and what they're moving to is preact So if you don't know what Preact is, it's basically a very tiny 3 kilobyte library that allows you to manipulate the virtual DOM and if I scroll down here to an example you can see it looks very similar to react and if you use the compatibility layer they offer it literally is react with a few missing features but most of them are there and what it allows you to do is basically efficiently use the virtual dom and manipulate it actually faster than react at least according to their docs and you can either use JSX or you can use this approach Which is kind of the equivalent of react.createElement and rendered in the body of the document So react is pretty cool I am not sure what they're gonna do because if you look at the article here They also mentioned that it's a fork of preact So it might be a completely different thing than the official preact branch so we will see in the future but what they want to do is have a mature virtual DOM manipulation library to add anything they want on top and from the looks of it they also want to revive Reach UI which after checking their website seems to be very old but I guess we will have to wait and see and if you didn't think that Remix was close to the web enough Remix version 3 seems to be even closer and that's what they're aiming to do and that's what you're gonna see in the rest of the article as well which they also mention in this sentence where they basically tell you okay this is as aligned as with the web platform as possible and one of the most important parts is the principles part and we're gonna go through each one of these points and the first one is model for development so what they're aiming to do is basically you have this thing that you might have heard about it's called an LLM and from what I understand it's some sort of AI thingy and they want to have it as a first-class citizen so that's really interesting I don't know how to feel about this point I personally haven't seen LLMs be useful as much I'm hoping they can prove us wrong because they have done that in the past So I am all open for them proving me wrong just to speculate on what this could be.

05:50 Maybe it's a built in MCP server, maybe it's LLM.txt and stuff like that built in. Maybe it's something completely different. Maybe they even build their own code editor, who knows. But yeah, Model First Development is something that no framework has done and for probably good reason and now that they are kind of unbound and able to do whatever they want, it's going to be interesting to see what they actually mean by this, because at the moment it's just a big question mark. The second point, we don't really have to go through it.

06:22 It's built on web APIs. If you've used Remix, you know their philosophy and they're all about using the web platform. So this one is a given. The religiously runtime is an interesting one because I personally don't believe that being religious about anything in development is a smart idea because it leads you down a path of making compromises just to religiously follow a rule that might not be good in all situations. So I'm interested to see what this turns into.

06:52 From what I've seen they don't really plan to make it their own ecosystem and no JavaScript ecosystem can interact with it, but rather the opposite. From what I've seen it almost seems like it will be pluggable into anything and I'll talk about this more when we get to 0.6 but that's what it feels like and for example they don't even want to use stuff like bundlers compilers typegen and stuff like that and they just want to have it run in node natively and they're gonna use import loaders from node to import and do some simple transformations like TypeScript and JSX and if you don't know node loaders basically allow you to transform the code easily so they don't want to depend on something like Vite but rather be independent of any bundler and stuff like that which is an interesting choice and I'm all for it but let's see what it turns into. The fourth one is avoid dependencies. This is also an interesting one because what they say is that dependencies lock you into somebody else's roadmap and you should choose them wisely and wrap them completely and expect to replace them. I actually really resonate with this because I've been thinking a lot on how to actually achieve this, especially in context of monorepos.

08:10 For example, let's say you want to use an auth module that's not really Dependent on the underlying auth implementation. So for example, you have a module that's used for authentication And you get stuff like login, logout, create user, get user, blah blah blah But you don't really care what it uses underneath. So for example, let's say you use better off or next thought or whatever, the wrapper around that always exposes the same API APIs, but the underneath structure changes. And if you use something like Knux, it's almost like Knux adapters where you use a specific adapter for a specific framework. So this is an approach I love and I fully resonate with so I'm really excited to see what they have planned for this.

08:57 And the main composition is also something that ties into the fourth one and basically what I just said so abstraction should be a single purpose and replaceable and I think what they're referring to in this complete segment is to remix the web by MJ And if you look at the packages inside of Remix the web you have something like file storage, fetch proxy, form data parser, headers, lazy file and so on and so forth. And basically all of these are very small packages and they allow you to do some very specific things like headers allows you to easily manipulate headers, multi-part parser allows you to parse files from form submissions, node fetch server allows you to create a request slash response middleware that allows you to handle anything in node that express with the request and response objects and I think that's what they're going for with this point and they're probably going to grow this package or the remix ecosystem even more with this but this now becomes a problem where you have like 20 packages and you have to re-export them and if you read this last sentence here, tightly coupled modules that almost always change together in both directions should be moved to the same package and then in the distribute cohesively they also mention this where they say that everything will be wrapped up into a single package and dependencies and re-export as a single toolbox.

10:21 And now this part here is the really interesting part, which kind of maybe gives it away in a sense, because I have a feeling what they're gonna do is probably create something that's pluggable into everywhere and everything is pluggable into Remix itself. So what could this mean is something similar to something like Backend as a Service but open source and free where you get some sort of back-end toolbox that allows you to plug it into anywhere even with something like Next and then use everything that Remix offers out of the box and enhance the experience And I've also seen Pedro talk about the fact that they don't want to move away from wheat and want to allow weeds To be plugged into whatever this is so I think that's also an interesting point And it might be that we don't get a framework but rather some sort of toolbox that allows you to do a lot of things that every project needs something like file uploads, databases, streaming, AI chats, stuff like that. So I think the distribute cohesively gives a lot more info than it aimed for or I'm just a tin foil hat wearing conspiracy theorist who got it completely wrong it's one of the other and you'll see in the future I guess and that's it for the article the last section mentions the remix jam that they're posting is going to be in Toronto in Ontario and I think it's happening on 10th and 11th of October so if you can come feel free to come I'm gonna be there and a lot of other influential people from the react to our community and the remix community are gonna be there So I'm really hoping you can join us and not have to look at me through a camera lens But rather through your eyes.

12:13 I heard they have a better Resolution than cameras. So that's really cool. And yeah, that's pretty much it for today I hope you enjoyed it and thank you for watching see you in the next one bye