How React Router Became a Framework

All right, thank you. So as you heard, my name is Mark Dalglish, all the way here from Melbourne, Australia. And as you heard, also, I'm here to talk about how ReactRouter became a framework. It's obviously a very big topic, so I'm going to touch the surface of it, but hopefully give you a good sense of where this move came from.

Now, as you heard as well, there, I've been working in the React space for a very long time. I've actually been working with it for about 10 years at this point. And that work has led me to my current position, working full-time with the Remix team at Shopify, a very privileged thing for me to be able to do at this point in my career. I'm really enjoying it.

And when I go back to the start of my career working with React, for me it really started with ReactRouter, because what got me interested in React was the fact that I could do server rendering, progressive enhancement, and do that with shared code between the client and server. And the first time I saw this done for real, in a way I could take to production, was in this ReactRouter mega demo that Ryan Florence put together about 10 years ago. And what was really great about this demo is it showed how you could get server rendering and data fetching working together. And the way it was done by convention in this boilerplate was that each route component could have this static fetch data method on it that would describe how do I get the data for this route. And you could figure out after doing route matching on the server, you could figure out which of your route components had these functions on them. You could call them in parallel, take the data and pass it down, and also run this on the client as you navigate it around. So this is exactly what I used to take React to production. To take React to production way back in the early days of React. So it was a really great project.

Now I know by far I was not the only person to be building on top of ReactRouter, because even to this day, roughly half of all React DOM downloads are paired with ReactRouter. So there's huge adoption still in the React community today. Now today what I want to do is drill into this distinction between libraries versus frameworks. Because if we're talking about ReactRouter becoming a framework, it's important to describe what is the difference between where it is today and where it's heading. Because ReactRouter is a library, that's not a controversial thing to say. Of course, it has always been a library since its first release. As it says right here in its readme, ReactRouter is a lightweight, fully featured routing library. But if you go to the React documentation for how to start a new React project, they tackle this question head on about whether you can use React without a framework. And they say that, of course, while you can use React without a framework, we're at the point now where there are so many big challenging problems to solve if you try to go it alone that you're much better off, the average developer is much better off using a framework. And they go further and draw a distinction with what they call production-grade React frameworks. And luckily, in terms of my work, luckily, Remix is on that list. So, Remix is featured as a production-grade framework.

So, Remix is featured as a production-grade framework. Here, it describes itself as a full stack web framework. But what's important for today's topic is that Remix is built on ReactRouter and quite heavily so. To the extent that if you go look at one of the packages that you use quite heavily throughout your Remix project, Remix run slash React, you go look at the source code for that package, and what you're going to see right up top is a giant wall of reexports from ReactRouter DOM. If you're familiar with ReactRouter and you come over to Remix, you're going to find yourself right at home. A lot of those APIs are completely identical. And of course, Remix adds a bunch of stuff on top. But it means that the core DNA of Remix is really ReactRouter. So, you can think of ReactRouter sorry, Remix as ReactRouter, the framework. What's interesting about this relationship is it meant that making Remix better often meant making ReactRouter better. Because if we needed to add a big new feature to Remix, it would usually require changes to ReactRouter. If we wanted to clean up the code in Remix, it would often require us to remove it from Remix and move it over to a lower level within ReactRouter. So, there was this relationship ongoing as we worked further on Remix and improved Remix itself. This was especially notable with this post from Ryan Florence a couple years ago in 2022 about remixing ReactRouter. And this was announcing the fact that a lot of the best features of Remix were actually going to be starting to arrive for ReactRouter consumers. In practice, what that looked like is something like this where you could describe your route tree as you might have done previously. But now you could also attach things like loaders and actions to your route to your actions to your routes. So, now you're starting to get a lot of the benefits that you get from a Remix application inside of your regular ReactRouter app. This was extended even further with lazy loading of routes. So, no longer did you need to load the entire route tree up front when you were describing it this way. You could instead make it so that you would only load the code for that route if and when you needed it as you navigated around. So, in this case, this is your standard implementation where the lazy route is a dynamic import here of our dashboard route. And if you go look at the source code for that, what you can imagine is that it's going to have to return the API for what a route would typically be described as in line. So, that dashboard component might look like this here where it's exporting a loader, it's exporting an action, it's exporting its component. And if you squint, if you've looked at Remix before, this basically looks like the same thing. So, you're using ReactRouter but you're getting a lot of those benefits and API decisions that you get out of Remix right here in ReactRouter. So, as a ReactRouter consumer, what you're getting now with this setup is nested routing. You're getting code splitting along with that and the simple state management model that makes Remix such a joy to work with while still being in the world of a library. This was notably picked up by a lot of people. Ken C Dodds gave a great talk at VConf last year highlighting that to him, ReactRouter, once it's gone down this road, ReactRouter tied with something like Vite really starts to feel like a framework and I completely agree with that position.

So, again, coming back to this distinction between libraries versus frameworks and if we want to drill in further now on the Remix side of things, it's worth exploring then what makes Remix feel like a framework. To me, the most notable thing up front is the fact that it has a CLI and it owns the start of your entire dev and build lifecycle. So, if you want to start up a dev server, you're calling out to the Remix CLI and saying Remix dev if you want to build for production. Likewise, you're running Remix build. Along with this, of course, you also had yet another config file on the root of your project, Remix.config.js and this describes how your dev server, how your build process and those sorts of things should operate.

Remix also had very strong opinions about the shape of your file system. So, there were certain files that needed to exist here like your root route, then your routes directory. By default, there was file system routing hooked up that all of this would get picked up based on the file system, the naming convention of your files. You could disable this and bring in alternatives or go purely config based, but this was the default setup with Remix. And along with this, of course, people expect a whole bunch of features out of a framework like Remix where we needed to support TypeScript out of the box, static asset imports, a bunch of CSS features like side effect imports, CSS modules that, of course, I worked on, post-CSS support, alternative file types like MDX, and then you get into the world of hot module reloading and polyfills for node APIs in the browser, particularly to support third-party packages on NPM. So, all of these sorts of things need to be managed by the bundler, and this is being owned by Remix in this case.

With Remix, it was built on top of ESbuild, particularly because of its performance benefits over the alternatives at the time, so ESbuild proved to be a really great project for us to build on top of. But what we realized, of course, working on this for a number of years and a lot of my work going into this space in particular, owning the bundler is really hard. It's a lot of responsibility to take on, and that list of things people want from the bundler just continues to grow. And particularly when we started to go into some of these more difficult features around hot module reloading, which was not built into ESbuild, we had to add that on top, configurable node polyfills, and when we started to prototype dependency optimization to speed up builds for especially large NPM packages, we realized that effectively what we were doing is slowly reinventing an admittedly worse version of Vite.

So the natural question for us that we asked ourselves at this point was, why don't we just use Vite? And this is something that the community, the Remix community was already pushing for. There was a discussion around it, a lot of upvotes, a lot of people for other reasons wanting us to go down the road of being built on top of Vite. So to us it felt like this was more and more feeling like the natural next step for us on the bundler side of things.

And so in October of last year, we announced that we were shifting to Vite. We were shipping an initial unstable release to get some early feedback, but the goal was for us to move over to Vite as our standard way of building Remix apps. Now I'm sure I don't have to tell a lot of you that Remix, sorry Vite, is really great tooling for JavaScript developers, but I want to flip it around today and highlight the other side of this, which is that as a framework maintainer, it's a really great platform for frameworks. And that's why we're seeing so many frameworks today built on top of Vite.

So when we started going down this road, we really wanted to lean into this philosophy of saying that Remix is just a Vite plugin. We wanted to see how far we could take this. And so in our initial unstable release, this is what it looked like. You would have your Vite config written in TypeScript, which is great, not something you could do in Remix as of that point. And you would bring in the Remix plugin and add it to the plugins array in your Vite config. That meant that no longer was there yet another dedicated config file on your project. You would just hook into the existing Vite setup that you might already be using, especially if you're using tools like Vitest and that sort of thing.

So you've got your Viteconfig.ts sitting there. That meant that as a consumer now, you're not talking to Remix as your starting point, you're talking to Vite. You run Vite dev to start up your dev server. And similarly, slightly more complicated, but here when you're running the build, there's a couple of steps. You would run Vite build, which runs your client build, and that would be followed by Vite build with the SSR flag to build your server. So one after the other.

But there's one big limitation with this model that we ran into, and that's that consumers had hard-coded the build process into their build scripts. So that meant if you looked at a project built on top of Remix Vite, you'd look at their build script and you'd see that command I showed you before, right there in the package JSON, Vite build and Vite build SSR. But the problem with this is that frameworks need more control. It's not something really that consumers should be owning. And that's because frameworks need to have control over the number of builds, the order of them, like whether it's the client build first before the server build or reversed. The communication between those builds is important, and once the build is finished, there may be additional logic you need to run, maybe to adapt it to a different platform, that sort of thing.

So when you put all this together, there's this overarching requirement of build orchestration that wasn't being managed by Vite, and if we put Vite in your hands as the primary touch point, it was now your job to manage the build orchestration. So this became a problem for us, and we unfortunately had to step back a little bit from that philosophy of being just a Vite plugin. So when we shipped the stable release of Remix Vite and made it the standard way to build Remix apps going forward in February of this year, 2024, we had to switch that philosophy a little bit and say that Remix is mostly just a Vite plugin.

Now, as a bit of a side note, luckily Vite is a moving target in a good way. They're always adding new features that make it an even better platform for frameworks, and so in April this year, Patak here on GitHub announced the upcoming environment API for Vite. Now this adds a bunch of new functionality to Vite, but notably for the purposes of this talk, it adds the concept of a Vite builder that lets frameworks orchestrate all the environment builds they need to get a single Vite build command to build the whole app. And they went on to say that this means that they're changing their stance on the framework as a plugin pattern, making it first class from Vite 6 forward. So as a framework maintainer, this is huge. This is Vite saying we're gonna take even more responsibility of what it is to build a framework on top of Vite.

With this new API, it meant that no longer would you hard code that you're running a client build followed by a server build. Instead, you just run Vite build with the app flag, and this would then delegate to the Vite builder that they described earlier. Effectively, what this means is that in your Vite config, you can configure a builder, but in practice, this would be set up by one of the plugins you're using. And in that, there's a build app hook, which has the builder instance passed to it, and this has access to the environments that you're building. Now, these environments are configurable. Frameworks can set up which environments they need. In our case, that might just be a simple client and server set of environments.

Frameworks can set up which environments they need. In our case, that might just be a simple client and server set of environments. Now, naively, you might just run those in parallel. If there's any dependencies, this can be managed here. You can run the client build first, in our case, followed by the server build. So the plugin can take full ownership of how exactly the build process should work. So when you put all this together, Vite is really doing a lot from a framework maintainer perspective. Vite's giving us a really great bundler with sensible defaults. So a lot of those features that I listed earlier, we had to add on top of esbuild. These just come out of the box with Vite. But the whole thing is configurable and pluggable, and those plugins are composable. So it's trivial to add a bunch of them together. You get that great development environment with module reloading, preview server if you need it, and build pipeline. And now with the environment API, we're getting this framework as a plugin pattern. So given all of these features that Vite's giving us, it's a good question to ask what's left for a framework?

The way I think about it is that there's almost this more minimal take on a framework that's coming out of all of this power given to us by Vite, which is this pattern of conventions as a plugin rather than necessarily being thought of as a framework. And that's because everything else is the usual library code, if you really lean into this model. We found ourselves from a Remix perspective looking at code like this and saying, if I'm importing components or other APIs from a package like Remix run React, what even is Remix at this point? If the vast majority of the bundler-specific things are being done by the Vite plugin, and that line between or that gap between what Remix is and what React Router is continues to shrink, why not just get rid of the indirection and have consumers import these things from React Router, the underlying library, directly? It seems like a much simpler mental model, much simpler way to think about things, and the code gets to live in a single place, which is great for us as maintainers as well. And so that's why in May of this year at React Conf, we announced that we were going to be merging Remix as it exists today into React Router. So all of these great build time framework features that you expect out of Remix are going to be available to the average React Router consumer. And this is going to be made available in the upcoming React Router v7. There's a pre-release out now if you want to jump on early and give us some feedback, but it's coming very, very soon.

So what this looks like is very similar to what we saw before with Remix. In your Vite config, you can pull in the React Router plugin from React Router slash dev slash Vite, and you add the React Router plugin to your Vite plugins array. As I said before, because that build orchestration layer is still needed, because we don't yet have the environment API available, you do need to run React Router Dev to start up your dev server and React Router build to start your build process, but this may change in the future. So now that React Router is giving us a lot of these extra features, now it's got its own CLI. It's managing the entry points to your application and including the commands you have to run. It gives you an official version now of the route module API that we got with Remix. You get file system routing, server and client rendering conventions, and now with added features more recently as well with spar mode and pre-rendering. It's a pretty full featured set here and so it's fair to look at this now and say that React Router is now a framework. But what's interesting I think is that it is still a library, so all of the existing APIs that you've come to know and love from React Router 6 today are still there, so you can continue to ship as you do today with or without the Vite plugin, with or without Vite, you can use alternative bundlers.

All of those lower level library APIs are still there. So an interesting midpoint, I think, another way to think about it, is that React Router is a library that also has a Vite plugin, again following that conventions as a plugin pattern, where we ship you a plugin that helps you best use the library if you like but it's completely optional. This has already started to impact our API design, especially as we're moving features from Remix back over to React Router.

A really great example of this is how now in React Router v7, file system routing is not the default as it is in Remix. So instead you configure your routes that are discovered at build time via this routes.ts config file and it looks like something like this where you can export an array of route config objects. Here we're defining a route, an about route, we've got a layout with some children. Now in practice we don't really want you to be defining these objects, instead we've given you these clean helper functions for generating them in a nice type safe way and you've also got that route config type to make sure the entire route tree is valid. But all of this is evaluated at build time and it's all pointing to separate splitable route modules on disk. What's great about this model is because it's written in code, it's trivial for you to opt into file system routing if that's something you prefer.

So what that looks like with the official FS routes package that's part of the new React router v7 API, you have available the flat routes function which is basically your Remix v2 file system routing conventions available. And you can just call this function in your routes.ts file and this will hit the file system and figure out the route tree based on the files on disk, what they're named and so on. So if you want you can just console log the result of that flat routes there and you will see what the resulting file, what the resulting route tree should look like. So again if we go into the separation between libraries versus frameworks, I think what's interesting now is with this pattern of being a Vite plugin on top of a library is that you get to choose how opinionated you want React router to be.

So React router is a library as it always has been. But if you're going to start a new React project, again following the documentation and you're being told that, you know, they recommend that you use a framework, then it's fair to say now that officially React router is a framework too. Or using the words of the React documentation, a production grade React framework. And that's really great news if you're on that blue line, that half of React projects that are out in the wild today already built on top of React router. It's great news for you because it means that all of those battle tested framework level features that you get out of Remix are going to be available to you in the next version of React router. So if you're on that blue line or if you want to join us on that blue line, I really encourage you to upgrade to React router v7 and then try the React router vplugin whether on your existing project or on a new project to get a feel for it. And really see how it can help your development experience and how it can help with the quality of the end product that you ship to users, which ultimately is the most important thing. And of course we'd love you to let us know what you think. So join us in the discord, give us any feedback, especially while we're in pre-release, so jump on early and yeah. I'd love to see what you think about the new vplugin. So that's it for me today, thank you so much for listening.

Okay, so we do have a lot of questions and we have, you know, it was a kind of like a high level, you know, talk about a lot of the philosophy that, you know, you have around, you know, this sort of change. And I think a lot of the questions reflect that as well, a lot of like really high level questions which I think is good.

So let me start with the most upvoted by far question, which is is there anything more that you can already tell about the Remix brand in the future now that Remix, as it exists today, is swallowed by React router? Yeah so there's another aspect to why we wanted to make this move. I didn't include it in the talk because what I like is that you don't need to have this context for this move to make sense. But this, one of the big drivers was we were already exploring what the next generation of Remix is. And some of these early explorations that are actually quite far along, it's effectively a different framework.

And it's such a, it was such a big change. But we were still bringing that spirit of backwards compatibility that's always been there with Remix and React router. So we were talking about letting you mount a React, sorry, a Remix v2 app instead of Remix v3. And that's when I was starting to get a little bit nervous because I'm like I don't want us talking about inversion numbers. And so there would already been talk about doing this, but I was the one who actually suggested like maybe the cleanest way to make this kind of move is to say let's take Remix as it exists today and move it over to React router. And then that frees up the Remix brand to sort of live side by side even into the future.

So it's about, it's really about decoupling the two philosophies. And that made perfect sense because as I said, if Remix is effectively React router, the framework, it's like it's going back home to where it really belongs in the long term.

Yeah. So Michael and Ryan have been the ones most closely working on it while we do a lot of the work on Remix as it is today and React router. But the goal is once the dust has settled on the React router v7 release for us to, as a team, start to put a bit more focus on that next gen version of Remix. But as of right now, it's not something I'm super close to.

Yeah. I mean, when I was like listening to the presentation, I think it was really delightful to kind of like hear the reasoning that seemed to come from a like a purely sort of like what makes sense perspective, right? Like a lot of, you know, frameworks these days are, you know, sort of also companies, you know, like, and they have sort of like a need to also sort of do things for kind of like a branding and packaging and molting and, you know, all those kinds of things. But this seems like a movement towards like a more sort of pure open source, like here, here's all the functionality and we have no claim to the sort of IP of it in a way. Is that also your sort of read on it or?

Yeah. I mean, what I like about the Remix team working on it and is there's always been such a focus on simplicity and removing things and that always happened to me when I put my own work forward, like the Routes TS work that I showed before. That's something I worked on where a lot of my early work was, you know, adding these layers of abstraction and indirection, because I'm like, we might want to support this in the future and support that. And Michael and Ryan are much more in the camp of like, if we don't need it, let's not add it yet. Let's focus on keeping things as simple as possible.

I mean, what I like about the Remix team working on it and is there's always been such a focus on simplicity and removing things and that always happened to me when I put my own work forward, like the Routes TS work that I showed before. That's something I worked on where a lot of my early work was, you know, adding these layers of abstraction and indirection, because I'm like, we might want to support this in the future and support that. And Michael and Ryan are much more in the camp of like, if we don't need it, let's not add it yet. Let's focus on keeping things as simple as possible.

And I think that this move from going from Remix to React Router is another example of that of saying, let's just cut out layers of indirection of, you know, you have to have a framework on top of a library and all these different APIs. I didn't touch on it in my talk, but like with React Router V7, we're actually dropping the React Native layer as well, because not many people were using it and that added complexity to the API. So there's no longer a React Router DOM. It's all just React Router. So most of you, I'm sure pretty much all of you who are using React Router are using React Router DOM. Now it's just React Router in V7. So it's like further simplification, just everywhere we can do it. Yeah. Yeah.

I mean, that's a, there's a great answer. And I think one thing you can say for Michael and Ryan that they have not been afraid of making breaking changes in the past. So, you know, they're very, very brave in that regard. There is a kind of question, which I think you sort of answered in the, in the, in the sort of like negative already, but is there a concern that React Router is growing too large for its scope? Like, is there, are there things there that like most consumers are just going to go like, well, that's not for me. Yeah. I mean, it's a fair question. I think. I don't think so because I think it's, it's a really good separation. Like I said, the conventions as a plugin angle is, is a really good one to me because it's, it's saying that the underlying library is still there. If you, if you want to skip the beat plugin and just use it as a library, nothing has effectively changed for you. But the challenge for us, you know, maintaining a library like React Router and React itself as having the same challenge that's driving it towards server components is some of these problems that people have when building an application, like architectural problems, start to touch the bundler and it, you know, because you're answering questions of like, how do I do code splitting? And how do I know, like, how does my server communicate to the client, the two different builds and make sure that there's good handoff happening and that sort of thing. There's all these problems that if you're just a library, there's really no good way to just give people a drop-in solution. All you can do is give them boilerplates and say, here, you know, here's a bunch of code for you to copy and paste to make a good server rendered architecture on top of React Router. And so to me, it's just adding that extra, like, convenience layer on top to say, if you want, again, it's opt in. If you want, here's a Vite plugin that's our opinion of how best to create a good architecture on top of React Router, but it's in its own separate place in the stack that, again, you can ignore it if you like. So I think, to me, it's a good example of how to have the best of both worlds. Nice.

We have a few questions here that are about Vite. So in the theme of Vite, I'm going to bundle them together into one, and then you can sort of like figure out how to answer it as well. So the questions really are, you know, one, how might Vite's recent venture funding affect Remix? So what are your thoughts on the different OSS funding models? And then broadly, sort of, are there any plans to make Remix a supported plugin by other bundlers? Or is Vite sort of like the, you know, is this kind of like a marriage? Yeah.

On the Vite funding thing, it's not even something I've really thought about. Like, it didn't strike me as a concern at all, so I don't really have much to say. Maybe whoever asked me the question, maybe come chat to me, there may be more to it than I'm missing. But yeah, if anything, it helps me feel more confident in betting on Vite in the long term. In terms of, what was the other question? Yeah. Do you plan to sort of add some of the other bundlers? Yeah. That's a really good question. It's an obvious question once we start saying, you know, we're supporting Vite as a Vite plugin. It's a really obvious question of, like, what about other bundlers? And it's a really tricky one, because I think as with anything of this nature, there's always a bit of a risk in terms of spreading yourself too thin. Because even just supporting Vite takes a lot of work when you factor in things like, we've got to support hot module reloading, and there's a bunch of integrations we have to do there. It's not a trivial thing to support Vite. So I think if there was enough demand, we definitely have to consider it. But I think we're in that early stage where, because we're still proving it out as a model, like in the sense that we're now moving it over to React Router, we probably wouldn't be in a hurry to spread ourselves too thin across supporting different bundlers. Vite is the clear leader at this point, which makes it easier for us to invest there. That said, another aspect of us having that clear separation of the Vite plugin versus the library, is it means that if that's something you really care about, it's open source, you can go look at the source code for the Vite plugin, and you'll get a good sense of what it might take for you to do a similar implementation on top of RSPack or whatever else it is. So if you want to do that, that would be great, and that would probably help speed things along, whoever asked the question. Oh yeah, PR is welcome, as the old saying. Put it in its own repo, you don't have to ask for permission, just go do it, and if you get some adoption too, then that'll help as well. Nice.

Okay, we have time for one more question, so I'm just gonna go with the higher voted one here. Is React Router going to support React Server components? Is this something that you're planning? It's definitely the plan. When we've demoed publicly prototypes of it working, there is a bit of a challenge in terms of timing, because it's relying on the environment API I talked about earlier that's not stable yet, and it's relying on server components, which obviously which themselves are not stable yet, so there's a little bit of work involved there. But what's great about it is that it's, you know, the demo that we've showed, what I like is that it integrates really nicely into the current React Router paradigm where, you know, your loaders can return all sorts of data types now. That's something we've added recently, a lot more support for different data types you can return from a loader, and our vision of RSC is basically saying you can return React elements from your loaders and that's it. So that's the goal, but as I said we're somewhat dependent on other APIs stabling first. Nice, and that would be a really great way to button up, but there was one last question that I felt bad not answering because it's been there for a while, which was are there any plans to better define the order of nested routes loaders execution? This is a very needy question. That's a deep question.

I work more on the bundler side of Remix, so this might even be outside the scope of, you know, testing my knowledge. I think that there is an API that lets you do this, but you might even know, some of you might even know better than me. I'm deep on the bundler side.

Yeah, well this question asker was nice enough to put their name in there, so Dennis Nemetov. If you didn't have your question answered, maybe you can contact Mark and Mark can point you to the right person on the team. Yeah, yeah, yeah.

Well, thank you, Mark. That was all the time and all the questions we had, so thank you so much. Let's give a big thank you to Mark. Thank you. You are free.