Every product team eventually hits the same question: which React framework do we build on? It sounds like a technical detail, but it touches hiring, deployment, forms, data fetching, routing patterns, and how fast the team can ship under production pressure. Getting it wrong does not break the product immediately, but it creates friction that compounds over months.
The choice used to be Next.js versus Remix. That framing is now outdated. In December 2024, the Remix team officially merged Remix into React Router. The Remix documentation now states that "the latest version of Remix is now React Router v7." New projects wanting the full framework experience should start with React Router v7, not the older Remix package.
So the real comparison today is Next.js against React Router v7. Both are capable, actively maintained, and backed by serious engineering teams. The tradeoffs are real, not superficial.
TLDR
- Choose Next.js if you want the largest ecosystem, per-route rendering (SSR, SSG, ISR, RSC), or Vercel's edge and ISR features.
- Choose React Router v7 if you care more about web platform fundamentals, nested routing, progressive enhancement, and a predictable loaders-and-actions model.
- Both are production-ready. The deciding factor is usually your product shape (forms-heavy app vs. content hybrid) and your deployment target (Cloudflare/Deno vs. Vercel/Node).
What each framework is today#
Next.js#
Next.js is a React framework maintained by Vercel. The current version (16.x) uses the App Router as the recommended approach, built around React Server Components, nested layouts, and file-system routing under the app/ directory (Next.js installation docs). It supports multiple rendering strategies per route: static generation, server-side rendering, incremental static regeneration, and streaming with React Server Components. The Pages Router remains supported for older projects.
Next.js ships with Turbopack as the default bundler, first-class TypeScript support, and tight integration with Vercel's deployment platform. It is the most widely deployed React framework in production.
React Router v7 (formerly Remix)#
React Router v7 is the merged successor of Remix and React Router. According to the official merger announcement, the two were so closely aligned that the Remix team decided to eliminate the distinction entirely. What was planned as Remix v3 became React Router v7 instead.
React Router v7 brings Remix's framework features (loaders, actions, nested routes, form handling, optimistic UI, server rendering, and static pre-rendering) into the unified React Router package. Existing Remix v2 users can migrate by changing imports from @remix-run/* to react-router, with a codemod available to automate it. New full-stack projects should use npx create-react-router@latest and follow the React Router v7 framework docs.
The comparison at a glance#
| Feature | Dimension | Next.js (App Router) | React Router v7 |
|---|---|---|---|
| Routing model | File-system (app/ directory) | File-system + nested route config | |
| Data loading | Server Components, fetch in layout/page | Loaders per route segment | |
| Mutations/forms | Server Actions (async functions) | Actions + Form component | |
| Rendering modes | SSR, SSG, ISR, RSC, streaming | SSR, pre-rendering, streaming | |
| Progressive enhancement | Partial, via Server Actions | First-class design goal | |
| Caching model | Multi-layer: fetch, route, full-route | Loader-based, no built-in ISR | |
| TypeScript | First-class | First-class (typegen for loaders/actions) | |
| Deployment targets | Vercel, self-host, edge, Node, Docker | Node, Cloudflare Workers, Deno, Vercel | |
| Ecosystem / community | Very large | Growing, smaller than Next.js | |
| Hosting lock-in risk | Low with self-host; some Vercel features exclusive | Low; adapter model for multiple runtimes | |
| Bundle size control | Server Components reduce client JS | Fine-grained via loaders | |
| Learning curve | Medium-high (RSC mental model) | Medium (web fundamentals first) |
Where they differ, dimension by dimension#
Routing#
Next.js App Router uses the file system under app/. Each folder can contain a page.tsx, layout.tsx, loading.tsx, error.tsx, and route.ts (API). Nested layouts compose automatically. The model is powerful but introduces new files and conventions that have a learning curve.
React Router v7 uses a route config file (routes.ts) or file-based conventions, and every route can define loaders, actions, and error boundaries in the same module. Nested routes with parallel data loading have been a core design principle since Remix's inception, making the mental model consistent for complex route trees.
Both handle nested layouts, but the React Router v7 approach keeps data loading co-located with route files in a way many teams find easier to trace.
Data loading#
Next.js fetches data by making fetch() calls inside Server Components or route handlers. The framework adds request-level memoization and multiple cache layers (Next.js caching docs). This is powerful but requires understanding when data is cached at build time, at request time, or not at all. Incremental Static Regeneration (ISR) lets you revalidate pages on a schedule without a full rebuild.
React Router v7 uses loader functions that run on the server before the route renders. Each route segment can export a loader, and all loaders in the current route tree run in parallel before the page renders. The pattern is simple and predictable: one function, one place, returns data to the route component. There is no ISR equivalent, but React Router v7 supports static pre-rendering for routes that can be exported as static HTML.
Forms and mutations#
This is where the two frameworks diverge most clearly. Next.js uses Server Actions, which are async functions that run on the server and can be called from client components or forms. They work, but error handling, optimistic updates, and pending states require more manual wiring.
React Router v7 uses action functions paired with the <Form> component. The framework handles pending state, revalidation after mutations, and error boundary display automatically. The pattern is closer to how web forms have always worked (submit to a URL, handle the result) but with React rendering on top. For form-heavy product surfaces like onboarding flows, settings pages, or multi-step wizards, this model reduces boilerplate considerably.
Deployment and operations#
Next.js supports a wide range of deployment targets: Vercel (first-class), self-hosted Node.js, Docker, and edge runtimes. Some features, like Vercel's distributed ISR and edge caching behavior, work best or only on Vercel's platform. Teams self-hosting Next.js should verify which features require the managed platform.
React Router v7 ships with a runtime adapter model. Official adapters exist for Node.js, Cloudflare Workers, Deno Deploy, and Vercel. The adapter pattern makes runtime portability explicit and well-documented. For teams with infrastructure opinions, particularly those running on Cloudflare or wanting worker-based deployments, this is a real advantage.
Caching strategy#
Next.js has a sophisticated, multi-layer caching model. Understanding when a fetch() call is memoized at request level, when it uses the Data Cache, and when it hits the Full Route Cache requires careful study of the Next.js caching documentation. This complexity pays off for high-traffic marketing pages and content sites. For product apps with user-specific data, the same caching model requires care to avoid serving stale or wrong data.
React Router v7 does not have a built-in data cache between requests. Each loader runs fresh per request unless you implement caching yourself. For most product apps this is fine and simpler to reason about. ISR-style patterns require reaching for a separate CDN strategy, as covered in our post on how CDNs deliver web apps.
Real-world scenarios#
Common wrong choices#
Choosing Next.js because it is the default. Next.js is a strong default, but not for every team. If your product is form-heavy, uses nested route layouts extensively, or runs on Cloudflare Workers, defaulting to Next.js without evaluating the alternative creates technical debt.
Treating Remix as deprecated. Remix is not abandoned. It became React Router v7. Teams already on Remix v2 have a clear migration path. Existing Remix v2 projects do not need to panic-migrate; the docs confirm you can continue using Remix v2, with React Router v7 being the forward direction.
Choosing a framework for RSC support without a plan. React Server Components are powerful but require a different mental model for component design, data flow, and third-party library compatibility. Picking Next.js specifically for RSC without team training and library vetting adds risk.
Ignoring deployment context. If your organization runs on Cloudflare or a non-Node runtime, choosing Next.js for its Vercel integration creates operational friction. Runtime fit matters as much as developer experience.
How to pick: a recommendation framework#
Most teams overthink this. The decision usually collapses into two questions: do you need an ecosystem or edge feature only Next.js offers, and is your product forms-first with deep nested routing? Walk the tree below before reading the detailed pros and cons.
The diagram is a starting point, not a verdict. Team familiarity can override it, which is why the pros and cons below add the nuance the tree leaves out.
- Choose Next.js: Large ecosystem, Vercel hosting, ISR for content-heavy sites, RSC for reducing client JS, broad third-party library support
- Choose Next.js: Team already familiar with Pages Router or App Router patterns
- Choose Next.js: Hybrid marketing + app use case where ISR is valuable
- Choose React Router v7: Form-heavy product surfaces where the actions model pays off
- Choose React Router v7: Cloudflare Workers, Deno Deploy, or non-Vercel edge deployment
- Choose React Router v7: Teams that value web fundamentals and predictable server data loading
- Choose React Router v7: Existing Remix v2 projects (clear upgrade path with codemod support)
- Avoid Next.js App Router: If the RSC mental model adds confusion without clear payoff for your use case
- Avoid Next.js: If you need Cloudflare Workers deployment without Node.js fallback
- Avoid React Router v7: If ISR is a hard product requirement and you do not want a separate CDN strategy
- Avoid React Router v7: If your team needs the largest possible library ecosystem
Final decision guide#
Start with the deployment target. If you are on Cloudflare Workers or a non-Node edge runtime, React Router v7 is the cleaner choice. If you are on Vercel or a standard Node.js server, both work well.
Next, consider the product surface. Marketing sites and content-heavy products with ISR requirements lean toward Next.js. Form-heavy product apps with nested route complexity lean toward React Router v7.
Finally, consider team familiarity. A team already productive with one framework should not switch without a clear technical reason. The switching cost is real, and both frameworks build excellent products.
If you are starting a new project and the above dimensions are roughly equal for your situation, Next.js is a reasonable default because of ecosystem size. But if your product is primarily a dashboard or forms-driven application, React Router v7 will likely reward you with simpler code over time.
Key Takeaways#
- Remix and React Router have merged. The latest version of Remix is React Router v7. New full-stack React projects should use the React Router v7 framework docs.
- Next.js 16 (App Router) uses React Server Components, multi-layer caching, and file-system routing. It is the larger ecosystem with better ISR support.
- React Router v7 uses loaders and actions for a consistent, predictable data model, with first-class support for Cloudflare Workers and other edge runtimes.
- The caching model is a key differentiator. Next.js has built-in ISR and a sophisticated data cache. React Router v7 is simpler but requires external CDN strategy for caching.
- Form handling favors React Router v7 for complex product apps. Server Actions in Next.js work but require more manual handling of pending state and revalidation.
- Deployment context matters. Cloudflare/Deno runtimes are better served by React Router v7's adapter model. Vercel-hosted projects get the most out of Next.js.
- Neither framework is universally superior. The right answer depends on your product shape, team, and infrastructure.
FAQ#
Is Remix dead?
No. Remix evolved into React Router v7. The official announcement describes this as a consolidation, not an abandonment. Remix v2 remains supported, and existing Remix apps have a migration path to React Router v7 using a codemod to update imports.
Can I still use the Pages Router in Next.js?
Yes. Next.js continues to support the Pages Router alongside the App Router. The App Router is the recommended approach for new projects, but the Pages Router is not being removed. See the Next.js upgrade guide for migration details.
Does React Router v7 support React Server Components?
React Router v7 has RSC support listed as "coming soon" in the merger announcement. As of mid-2026, RSC is not yet a stable feature in React Router v7. Next.js remains the production-ready choice if RSC is a hard requirement.
Which framework is better for SEO?
Both support server-side rendering, which is the key requirement for SEO. Next.js adds ISR for static-but-fresh public content, which is useful for large content sites with many pages. For a typical SaaS product app, the SEO implications are similar.
How hard is it to migrate from Remix v2 to React Router v7?
The migration is designed to be straightforward. The Remix team committed to making the transition non-breaking except for import changes, provided you have future flags enabled and are using Vite. A codemod automates the import updates. See the React Router v7 upgrade guide for the exact steps.
Should I use Next.js if I am not deploying to Vercel?
Yes, you can self-host Next.js on any Node.js server or Docker container. However, some features (particularly distributed ISR and certain edge caching behaviors) work best or exclusively on Vercel's managed infrastructure. Review the Next.js self-hosting docs to understand which features apply to your deployment target.
