React Router vs Next.js: Why Popularity Isn't a Technical Argument (And What It Means for Shopify Hydrogen)

Next.js is the most popular React meta-framework. That's a fact. It's also irrelevant to whether it's the best technical choice for your commerce stack.

jQuery was once the most popular JavaScript library on earth. WordPress powers 43% of the web. Popularity tells you about marketing budgets and first-mover advantages — not about architectural superiority.

In this post, we'll do what the typical "Next.js vs React Router" comparison won't: look past download counts, examine the actual technical tradeoffs, and explain why Shopify chose React Router (via Remix) as the foundation for Hydrogen — its official headless commerce framework.

The Numbers Everyone Cites (And Why They're Misleading)

Next.js has ~59% usage among JavaScript developers, according to the State of JavaScript 2025 survey. That sounds dominant.

But here's what the same survey reveals when you dig deeper:

• Next.js satisfaction dropped from 68% to 55% — the largest decline of any framework in the survey
• Next.js generated more negative comments than any other project surveyed — 17% negative sentiment vs 21% positive
• Developers consistently cited complexity of Server Components and the App Router as primary frustrations

One survey respondent put it bluntly:

"I've written Next.js in production for going on 6 years... the Next complexity has gotten absurd."

Another added:

"While I did have a positive experience with Next, I'm worried because Vercel is trying to use it to make money."

Meanwhile, React Router (which absorbed Remix in v7) has been quietly building the features developers actually want — without the complexity overhead.

Feature-by-Feature: React Router v7 vs Next.js

Let's stop talking about vibes and look at actual capabilities. Here's what both frameworks support in 2026:

Server-Side Rendering (SSR)

Both frameworks handle SSR. The difference? React Router gives you SSR, SSG, and SPA mode through a single, consistent API. Next.js forces you to reason about "use client" vs "use server" boundaries, App Router vs Pages Router, and a proprietary caching layer that breaks on non-Vercel platforms.

Data Loading

React Router's loader/action pattern is elegantly simple:

// React Router: One pattern for everything
export async function loader({ params }: Route.LoaderArgs) {
  const product = await getProduct(params.id);
  return { product };
}

export default function Product({ loaderData }: Route.ComponentProps) {
  const { product } = loaderData;
  return <h1>{product.title}</h1>;
}

Every route has a loader (reads data) and an action (writes data). When an action completes, all loaders on the page revalidate automatically. No manual cache invalidation. No revalidatePath(). No stale data bugs.

Next.js requires you to juggle fetch() with caching directives, generateStaticParams(), revalidateTag(), Server Actions, and client-side data fetching — often within the same page.

Nested Routes and Layouts

React Router pioneered nested routing. Every route can have its own loader, error boundary, and layout — and they compose naturally:

routes/
├── _layout.tsx          → App shell
├── products/
│   ├── _layout.tsx      → Products layout
│   ├── $id.tsx          → Product detail
│   └── index.tsx        → Product list

Next.js adopted nested layouts in the App Router (v13+), but the migration from Pages Router to App Router has been one of the most painful transitions in React ecosystem history. Many teams are still running both routers in parallel years later.

React Server Components

Here's where it gets interesting. React Router now supports RSC too — but with a critical difference in philosophy.

Kent C. Dodds, creator of Epic React and long-time React educator, praised React Router's RSC approach:

React Router lets you opt into RSC per route, keeping your existing loaders and actions intact. You can return UI from loaders, make entire routes server components, or mix and match — without rewriting your app.

Next.js made RSC the default. Every component is a server component unless you explicitly mark it with "use client". This all-or-nothing approach created a massive complexity cliff that the community has been struggling with since 2023.

The Vendor Lock-In Problem

This isn't theoretical. It's architectural.

Next.js implements aggressive caching that presumes Vercel's deployment model. ISR, edge middleware, image optimization — these features work seamlessly on Vercel and degrade on every other platform.

A Hacker News commenter summarized the sentiment:

"NextJS is a pile of garbage, and their platform is absurdly expensive and leans heavily on vendor lock-in."

Even a Cloudflare engineering manager rebuilt a Next.js clone in one week to prove the point — the framework's value proposition is inseparable from Vercel's hosting business.

React Router has no hosting preference. Deploy on:

• Shopify Oxygen
• Cloudflare Workers
• Fly.io
• AWS Lambda
• Any Node.js server
• Deno Deploy

Same code, same behavior, everywhere. That's not a feature — it's a fundamental architectural philosophy.

The Security Argument: Complexity Creates Attack Surface

In April 2026, CVE-2026-23869 hit React Server Components — specifically affecting Next.js App Router applications running versions 13.x through 16.x. Amazon threat intelligence teams observed exploitation attempts by multiple state-nexus threat groups within hours of disclosure.

This wasn't a random bug. It was a direct consequence of RSC's complexity — the very complexity that Next.js forces on every project by default.

React Router's approach? RSC is opt-in. If you don't use it, you don't carry the attack surface. And because Shopify Hydrogen runs on React Router without RSC by default, production Hydrogen storefronts were not directly affected by this vulnerability.

Less complexity = less attack surface. This isn't an opinion — it's a security engineering principle.

Why Shopify Chose React Router for Hydrogen

Shopify didn't pick React Router by accident. They evaluated the landscape and made a deliberate architectural decision:

1. No vendor lock-in — Hydrogen deploys to Oxygen (Shopify's edge platform) but works on any hosting provider. No infrastructure dependency on a third party.

2. Simpler mental model — Loaders, actions, nested routes. Developers learn one pattern and apply it everywhere. No "use client" / "use server" boundary confusion.

3. Stability — React Router doesn't break between major versions the way App Router broke Pages Router. The Remix → React Router v7 transition was one of the smoothest framework migrations in React history.

4. Performance — SSR benchmarks from Platformatic show Next.js struggles at 1,000 req/s without aggressive caching. React Router's lighter runtime doesn't carry the RSC overhead by default.

5. Commerce-first architecture — Hydrogen's built-in Storefront API hooks, cart components, and analytics integrate cleanly with React Router's loader pattern. Data flows from Shopify's GraphQL API through loaders directly to components — no intermediate caching layer to debug.

The jQuery Analogy (And Why It Matters)

In 2010, if you suggested building a web app without jQuery, people would have thought you were insane. jQuery had:

• The biggest community
• The most tutorials
• The most Stack Overflow answers
• The most plugins

Sound familiar?

jQuery's dominance wasn't because it was technically superior to emerging alternatives. It was because it had first-mover advantage and an enormous ecosystem moat.

Then Vanilla JS got better. Browsers standardized APIs. React emerged. jQuery didn't die overnight — it just became unnecessary. The sites that were fastest to recognize this had a competitive advantage.

Next.js is following the same pattern. Its dominance is built on:

• Vercel's massive marketing budget
• First-mover advantage in the React meta-framework space
• An ecosystem of tutorials and templates
• Integration with Vercel's hosting platform (which creates switching costs, not technical value)

None of these are technical arguments. They're business moats — and business moats erode when better alternatives mature.

React Router v7 is that alternative. It does everything Next.js does, with less complexity, no vendor lock-in, and a cleaner architecture.

What This Means for Your Commerce Stack

If you're building on Shopify in 2026, here's the practical takeaway:

Choose Hydrogen (React Router) when you want:

• Full Shopify-native integration — Storefront API, Customer Account API, B2B, Markets, all work out of the box
• Deploy anywhere — Oxygen, Cloudflare, Vercel (yes, even Vercel), self-hosted
• Simpler DX — loaders/actions, no RSC complexity by default
• Smaller attack surface — proven by CVE-2026-23869
• AI-ready architecture — Shopify's MCP integration is built for Hydrogen's data patterns

Think twice about Next.js when:

• You're building a Shopify storefront (you'd be fighting the grain)
• You need to deploy on non-Vercel infrastructure
• Your team is frustrated with App Router complexity
• You're concerned about the RSC security surface

The Bottom Line

React Router does everything Next.js does — SSR, SSG, streaming, nested routes, code splitting, and now RSC — with a simpler API, no vendor lock-in, and a smaller attack surface.

The only thing Next.js has that React Router doesn't is popularity. And as jQuery taught us, popularity is the last metric you should optimize for when choosing a technical foundation.

Shopify understood this when they chose React Router for Hydrogen. The question is whether you'll wait for the rest of the market to catch up, or build on the better architecture now.

Building a Shopify Hydrogen storefront? Weaverse gives you a visual editor on top of Hydrogen's React Router architecture — all the performance benefits, none of the code-from-scratch complexity. Check out our themes →