React Router (library mode) vs React Router (framework mode / formerly Remix)
A comparison of React Router, the standard client-side routing library for React, and Remix, the full-stack framework built by the same team — and how React Router v7 absorbed Remix's framework capabilities, largely merging the two projects.
Quick Answer
React Router v7 absorbed Remix's full-stack framework mode (data loading, server rendering, and file-based routing conventions) directly into React Router itself, meaning the historical 'React Router vs Remix' choice has largely collapsed into one decision: use React Router as a lightweight client-side router, or use React Router's framework mode (what used to be distinctly Remix) for a full-stack application.
Reviewed by TechLogHub Engineering Team. Last updated October 14, 2026. Updated to reflect React Router v7's absorption of Remix's framework-mode capabilities, following Shopify's acquisition of the Remix team, which now maintains both projects under one roadmap.
| Feature |  React Router (library mode) |  React Router (framework mode / formerly Remix) |
|---|---|---|
| Scope of Concern | Client-side routing only | Full-stack: routing, data loading, mutations, SSR |
| Server Rendering Support | Not included in library mode by default | Built in |
| File-Based Routing | Not required, routes typically defined in code | Yes, with colocated loaders/actions |
| Data Loading Conventions | Basic, without Remix's loader/action pattern | Loaders and actions built on web Fetch/Form APIs |
| Maintainer | Shopify (Remix team, now maintaining both projects) | Shopify (Remix team, now maintaining both projects) |
| Typical Use Case | Adding routing to an existing client-side React app | New full-stack React applications |
React Router (library mode)
The standard, long-established client-side routing library for React, used as a lightweight dependency within an existing React application to handle navigation and URL-based rendering without a full-stack framework's additional structure.
Pros
- Lightweight — adds routing capability to an existing React application without imposing a full-stack framework's broader architecture
- The most widely used, longest-established routing solution in the React ecosystem, with the largest existing base of tutorials and community knowledge
- Works within any React setup — Create React App successors, custom Vite configurations, or any client-side-rendered React application
- Minimal migration cost for existing React applications that just need routing, without adopting server rendering or file-based conventions
- Now maintained by the same team (via Shopify's Remix acquisition) that also builds the full-stack framework mode, ensuring aligned long-term direction
Cons
- Client-side-only routing mode doesn't include Remix's full-stack capabilities (server-side data loading, form actions, file-based routing) unless you opt into framework mode
- For applications that do need full-stack capabilities, using library mode alone means assembling that functionality separately rather than getting it built in
- Less opinionated structure means more upfront architectural decisions compared to framework mode's more guided conventions
- The historical distinction between 'React Router' and 'Remix' can be genuinely confusing given the terminology shift as the projects converged
Best For
Existing React applications that need client-side routing without adopting a full-stack framework's broader conventions, or teams specifically wanting a lightweight routing dependency rather than a complete application framework.
React Router (framework mode / formerly Remix)
The full-stack capability historically distinct as 'Remix,' now absorbed directly into React Router v7 as its framework mode — providing server-side data loading, form actions, file-based routing conventions, and progressive enhancement built on web standards.
Pros
- Full-stack capability built directly into React Router itself as of v7, rather than requiring a separate framework and separate ecosystem
- Web-standards-first data loading and mutation model (loaders and actions built on Fetch/Form APIs) that many developers find more predictable than alternatives
- File-based routing with colocated data loading keeps route logic and data fetching logic close together
- Progressive enhancement by default — forms and mutations work even before JavaScript has fully loaded
- Single team and roadmap (under Shopify) now maintains both the library and framework modes, reducing the confusion of historically separate projects
Cons
- More architectural commitment than library mode — adopting framework mode means embracing its file-based routing and data-loading conventions
- The terminology shift (Remix's capabilities now living inside 'React Router v7') has created genuine confusion for developers trying to understand current documentation and tutorials written before the merge
- Smaller ecosystem than Next.js specifically, which remains the more dominant full-stack React framework overall
- Migrating an existing client-side-only React Router application to framework mode requires real, deliberate additional work
Best For
New full-stack React applications wanting a simpler, more web-standards-first approach to routing, data loading, and form mutations than Next.js's Server Component model, particularly teams that appreciated Remix's original design philosophy.
How the Two Projects Converged
Remix was originally built by the creators of React Router as a distinct, full-stack framework layered on top of routing concepts. Following Shopify's acquisition of the Remix team, the two projects' roadmaps converged technically, culminating in React Router v7 absorbing Remix's framework-mode capabilities — server-side data loading, form actions, file-based routing — directly into React Router itself. This means what used to require choosing between two separate packages with two separate ecosystems is now a single project with two operating modes.
Why the Terminology Is Genuinely Confusing Right Now
Because the merge happened relatively recently, a lot of existing documentation, tutorials, and community discussion still refers to 'Remix' as a distinct framework, while current official guidance frames the same capabilities as React Router's 'framework mode.' Developers researching this topic should expect to encounter both framings and understand they're describing the same underlying technical capability — this isn't two competing approaches to reconcile, but one capability set that changed its primary name and packaging.
Library Mode vs Framework Mode Is the Real Decision Now
The practical question for a new project isn't 'React Router or Remix' anymore — it's whether your application needs just client-side routing (library mode) or a full-stack framework with server rendering, data loading conventions, and file-based routing (framework mode, Remix's former identity). This is conceptually similar to deciding whether a project needs a full framework like Next.js or just a routing library, except now that decision happens within one project rather than between two separately maintained ones.
How This Compares to Next.js
React Router's framework mode remains a genuine alternative to Next.js for full-stack React development, retaining the original Remix design philosophy of web-standards-first data loading and progressive enhancement, as opposed to Next.js's more React-Server-Components-centric approach — see our dedicated Next.js vs Remix comparison for how that specific choice plays out, keeping in mind that 'Remix' in that comparison now effectively means React Router's framework mode.
Verdict
The historical 'React Router vs Remix' choice has largely collapsed into one decision within a single project: use React Router in library mode if you just need client-side routing added to an existing React application, or use React Router's framework mode (what Remix's full-stack capabilities became) if you're building a new full-stack application and want its web-standards-first approach to data loading and mutations. Both are maintained by the same team under Shopify, so you're no longer choosing between two separate projects with potentially diverging roadmaps — you're choosing which mode of one project fits your application's scope.