How React Router Became a Framework

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

When Remix was first released in 2020, its goal was to provide framework-level features on top of React Router, simplifying server-side rendering, data fetching, state management and build tooling. Now, with the release of React Router v7, the entirety of Remix is getting merged back upstream into React Router. This is a huge step up for the React community since React Router powers roughly half of all React downloads. In this talk we'll take a look into how this happened and what this means for the future of React frameworks.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

FAQ

Mark Dalglish's talk focuses on how ReactRouter evolved into a framework and the distinction between libraries and frameworks in the context of React development.

Mark Dalglish has been working in the React space for about 10 years.

Remix is heavily built on ReactRouter, using many of its APIs and features. ReactRouter serves as the core DNA of Remix, which is considered ReactRouter as a framework.

It was announced that Remix would merge into ReactRouter, bringing framework-level features of Remix into ReactRouter v7, making ReactRouter a more complete solution.

Using ReactRouter with the Vite plugin provides features like nested routing, code splitting, and a simple state management model, enhancing the overall development experience.

The transition allows Remix to decouple from ReactRouter and explore new directions, potentially evolving into a different framework while maintaining backward compatibility.

Yes, ReactRouter plans to support React Server Components, though it is dependent on the stabilization of certain APIs.

The development is guided by a focus on simplicity, removing unnecessary layers of abstraction, and providing clear, concise solutions for common development challenges.

ReactRouter is traditionally a library, but with its integration of framework-like features, especially through its Vite plugin, it can also function as a framework, providing a more complete solution for React applications.

Mark Dalgleish
Mark Dalgleish
31 min
25 Oct, 2024

Comments

Sign in or register to post your comment.
  • Christos kuznos
    Christos kuznos
    None
    any slack channel available, to discuss further
Video Summary and Transcription
My name is Mark Dalglish and I'm here to discuss how ReactRouter became a framework. Remix is built on ReactRouter and heavily relies on it. Remix feels like a framework because it has a CLI, manages the dev and build lifecycle, and has strong opinions about the file system structure. Remix embraced Vite as a plugin, allowing developers to integrate it seamlessly into their existing Vite setup. The shift to Vite led to a change in the philosophy of Remix Vite, enabling frameworks to orchestrate all the environment builds and make the framework as a plugin pattern first class. React Router is merging with Remix to make all the build time framework features available to React Router consumers. React Router is now officially a framework as well as a library. The move to integrate Remix into React Router is driven by the exploration of the next generation of Remix. React Router V7 simplifies by dropping the React Native layer and allows flexibility for consumers to use it as a library or as a framework with additional architectural features provided by plugins. The focus is on betting on Vite in the long term, and React Router plans to support React Server components. Thank you to Mark for answering the questions.

1. Introduction to ReactRouter

Short description:

My name is Mark Dalglish. I'm here to talk about how ReactRouter became a framework. I've been working with React for 10 years and it led me to my current position with the Remix team at Shopify. ReactRouter provided server rendering and data fetching capabilities, which I used to take React to production. ReactRouter has a huge adoption in the React community, and today I want to discuss the distinction between libraries and frameworks, with ReactRouter moving towards becoming 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.

2. Remix's Relationship with ReactRouter

Short description:

Remix is built on ReactRouter and heavily relies on it. The core DNA of Remix is ReactRouter, and making Remix better often means making ReactRouter better. Features of Remix are now arriving for ReactRouter consumers, including attaching loaders and actions to routes and lazy loading of routes. ReactRouter coupled with tools like Vite starts to feel like a 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.

3. What Makes Remix Feel Like a Framework

Short description:

Remix feels like a framework because it has a CLI, manages the dev and build lifecycle, and has strong opinions about the file system structure. It provides features like TypeScript support, static asset imports, CSS modules, hot module reloading, and polyfills. Initially built on ESbuild, Remix faced challenges in owning the bundler and decided to switch to Vite.

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.

4. Embracing Vite as a Plugin

Short description:

The Remix community pushed for using Vite as the natural next step for the bundler. In October of last year, Remix announced the shift to Vite as the standard way of building Remix apps. Vite is a great tool for JavaScript developers and a platform for frameworks. Remix embraced the philosophy of being a Vite plugin, allowing developers to integrate it seamlessly into their existing Vite setup.

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.

5. Managing Build Orchestration with Vite

Short description:

Consumers had hard-coded the build process in their scripts, limiting frameworks' control over the builds. The requirement for build orchestration led to a shift in the philosophy of Remix Vite. Vite's upcoming environment API allows frameworks to orchestrate all the environment builds and make the framework as a plugin pattern first class from Vite 6 forward. With this new API, running a client build followed by a server build is no longer hardcoded. Instead, the Vite builder is delegated the task, configurable through a builder instance passed to the build app hook.

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.

6. Enhancing React Router with Remix Features

Short description:

Frameworks can set up which environments they need. In our case, that might just be a simple client and server set of environments. Vite is doing a lot from a framework maintainer perspective, providing a great bundler with sensible defaults and configurable plugins. With the environment API, we're getting a framework as a plugin pattern. Remix is merging into React Router to make all the build time framework features available to React Router consumers in the upcoming React Router v7. React Router now has its own CLI, manages entry points, provides official route module API, file system routing, and server and client rendering conventions.

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.

7. React Router as a Library and Vite Plugin

Short description:

React Router is a library that also has a Vite plugin. React Router v7 introduces a new configuration for routes, where you can export an array of route config objects. It also offers clean helper functions for generating route config objects and supports file system routing with the official FS routes package.

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.

8. React Router as a Framework and Library

Short description:

React router is now officially a framework as well as a library. Upgrading to React router v7 enables you to access all the battle-tested framework level features from Remix. Join us in the discord to give feedback on the new vplugin.

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.

9. Integration of Remix and React Router

Short description:

The move to integrate Remix into React router is driven by the exploration of the next generation of Remix. By decoupling the two frameworks, Remix can live side by side with React router. The goal is to focus on the next-gen version of Remix after the React router v7 release. This movement represents a pure open-source approach, prioritizing simplicity and removing unnecessary features.

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.

10. Simplifying React Router and Addressing Concerns

Short description:

The move from Remix to React Router is an example of prioritizing simplicity and removing unnecessary layers of indirection. React Router V7 further simplifies by dropping the React Native layer. The concern of React Router growing too large for its scope is addressed through the separation of conventions as a plugin. This allows flexibility for consumers to use React Router as a library or as a framework with additional architectural features provided by plugins.

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.

QnA

Vite, OSS Funding, and React Server Components

Short description:

The questions are about Vite and OSS funding models. There are no immediate concerns about Vite's venture funding, and the focus is on betting on Vite in the long term. Although supporting other bundlers is a possibility, the current priority is on Vite as the clear leader. React Router's plan is to support React Server components, but timing and stability of APIs are factors to consider. The goal is to integrate server components seamlessly into the current React Router paradigm.

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.

Bundler Side of Remix and Thank You

Short description:

There might be an API for the question, but it's outside my expertise. Dennis Nemetov asked a question and can contact Mark for assistance. Thank you to Mark for answering the questions.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Don't Solve Problems, Eliminate Them
React Advanced 2021React Advanced 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Full Stack Documentation
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
SolidJS: Why All the Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.

Workshops on related topic

Remix Fundamentals
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Workshop
Kent C. Dodds
Kent C. Dodds
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Building High-Performance Online Stores with Shopify Hydrogen and Remix
React Advanced 2023React Advanced 2023
104 min
Building High-Performance Online Stores with Shopify Hydrogen and Remix
WorkshopFree
Alexandra Spalato
Alexandra Spalato
I. Introduction- Overview of Shopify Hydrogen and Remix- Importance of headless e-commerce and its impact on the industry
II. Setting up Shopify Hydrogen- Installing and setting up Hydrogen with Remix- Setting up the project structure and components
III. Creating Collections and Products- Creating collections and products using Hydrogen’s React components- Implementing a Shopping Cart- Building a shopping cart using Hydrogen’s built-in components
VI. Building the home page with Storyblok- Cloning the space and explaining how it works- Implementing Storyblok in the repo- Creating the Blok components- Creating the Shopify components- Implementing personalisation
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
How to Solve Real-World Problems with Remix
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Workshop
Michael Carter
Michael Carter
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
Let AI Be Your Docs
JSNation 2024JSNation 2024
69 min
Let AI Be Your Docs
Workshop
Jesse Hall
Jesse Hall
Join our dynamic workshop to craft an AI-powered documentation portal. Learn to integrate OpenAI's ChatGPT with Next.js 14, Tailwind CSS, and cutting-edge tech to deliver instant code solutions and summaries. This hands-on session will equip you with the knowledge to revolutionize how users interact with documentation, turning tedious searches into efficient, intelligent discovery.
Key Takeaways:
- Practical experience in creating an AI-driven documentation site.- Understanding the integration of AI into user experiences.- Hands-on skills with the latest web development technologies.- Strategies for deploying and maintaining intelligent documentation resources.
Table of contents:- Introduction to AI in Documentation- Setting Up the Environment- Building the Documentation Structure- Integrating ChatGPT for Interactive Docs