Remix vs React Router Framework

TL;DR Remix and React Router are the same thing, made by the same people. Remix was simply renamed React Router Framework Mode starting in version 7 of React Router.

Remix has always been wrapper for React Router adding some conventions and server rendering. I would even jokingly call Remix the "React Router Framework" in workshops before the official rename. React Router can still be used for SPAs too if you wish (React Router has been the most popular router for SPAs in React since the beginning of React). So while the brand name "Remix" was replaced, the Remix framework isn't "dead" by any means, it was always been React Router and they just renamed it.

Fun Fact The creators of Remix and React Router are also the owners of ReactTraining (the site your on now 😁).

Here's the blog post that they wrote about updating from Remix 2 to React Router 7

For the purpose of this post, we'll refer to Remix when we're talking about version 1 and 2 and we'll say React Router when we mean that tool in a more general sense and we'll say RR Framework Mode when we mean React Router in that particular mode.

You may hear React devs refer to React as being a library but then we also use it with a Framework. Usually "as a library" coincides with being an SPA -- where they're likely to use React Router for client-side routing. The main idea of the frameworks is to bring server-side rendering to the table all while keeping some of the best aspects of SPAs. That's why I typically refer to the frameworks like Next and RR Framework Mode as being a hybrid (best of SSR and CSR).

Does that mean RR Framework Mode is kinda like NextJS? At a high level, I guess you can make that comparison but they also do many things differently from each other.

React Router on the server.

We've always been able to run React on the server ourselves with Express or similar Node servers and we've always been able to do React Router on the server with it.

Historically though, React by itself didn't have a strategy for data-fetching on the server. For example you can't run useEffect or any alternative client-fetching abstractions on the server. So imagine your doing React on the server (SSR) and you want to emit HTML from the server to the browser, but the HTML is more your static templates from JSX without any meaningful data populated into them. This is why people don't generally do React on the server without a framework. Frameworks like NextJS and RR Framework Mode are helping us do a really nice data-fetching strategies on the server.

For NextJS this is their getServerSideProps function, and for RR Framework Mode this is the loader function.

What happened to Remix?

Originally, Remix was extra stuff on top if React Router for the server. The short story is, they started replacing the Remix specific stuff with Vite and also moving some Remix stuff directly into React Router so devs could use those features SPAs. Remix specific code became so small that they decided to just rename it to be React Router in Framework Mode. Also, this helps older SPAs migrate their code to newer versions of React Router and then make a small leap over the modern RR Framework Mode if they wish.

Here's the longer explanation from the Remix team.

What happens to React Router for SPAs

If you were on React Router 4, 5, or 6, you might be gearing up for upgrading to 7 at some point. Version 7 of React Router is where you can choose between library mode and framework mode.

You can still use React Router 7 the way you always have for SPAs. Just know that the v7 API looks very similar to v6 which will be an easy transition from v6. But v6 is where they introduced "nested routes" which is very different from v4 and vr5.

But I heard Remix had a file-based router?

It did, similar to NextJS you would add your .tsx files in a certain folder and the names of the files were read by the framework to make your router. Some characters in the file-name like underscores and . had special meaning to the file-based router. Some liked it but some found it cumbersome. In React Router 7, the way you setup your routes can be different depending on if you're doing framework or library mode.

If you're doing framework mode, you'll probably do routes likes this:

import { type RouteConfig, index, layout, route } from '@react-router/dev/routes'

export default [
  layout('./routes/main-layout.tsx', [
    layout('./routes/products-layout.tsx', [
      index('./routes/home.tsx'),
      route('products', './routes/products-home.tsx'),
      route('products/:productId', './routes/product-profile.tsx'),
    ]),
    route('cart', './routes/cart.tsx'),
  ]),
] satisfies RouteConfig

Notice that it gives you that classic "nested route" feel but the file names and their organization is up to you. There are no special file-name things like underscores and dots. Name the files whatever you want and organize them in any folder you want in RR Framework Mode.

If you're doing Library Mode with an SPA, you can program your routes now with createBrowserRouter and you can still do the JSX approach to routing if you want with createRoutesFromElements:

const router = createBrowserRouter(
  createRoutesFromElements(
    <Route element={<MainLayout />}>
      <Route element={<ProductsLayout />}>
        <Route index element={<HomePage />} />
        <Route path="products">
          <Route index element={<ProductsHome />} />
          <Route path=":productId" element={<ProductProfile />} />
        </Route>
      </Route>
      <Route path="cart" element={<Cart />} />
    </Route>,
  ),
)

export function App() {
  return <RouterProvider router={router} />
}

Either way, you're telling React Router the same information, but the "framework mode" way locks you into a bit more convention because that's how they give you better type safety and automatic features oriented around loaders and actions (like revalidation).

Using React Router 6.3 or lower? You'll need to update to 6.4 to get createBrowserRouter.

What about React Server Components

RSCs are more of a specification from React, than an actual technology they give you. It's an ability to have an async component that await's data directly in the component on the server. As such, these components only run on the server and don't re-hydrate to the client. They require a framework to use them because again it's more of a spec and so a framework has to handle them. NextJS has implemented them and RR Framework Mode will do so soon.

Thanks for reading!