Did React Router Framework Kill Next.js?

As frontend developers, we tend to talk in binaries: X killed Y, this is the future, that’s dead. The past years' rise of React Router Framework mode (v7+), born from the Remix merge, triggered exactly that kind of debate — especially when developers started claiming it felt cleaner and faster than Next.js for real-world SPAs.

And there’s a third name that keeps coming up more and more in serious discussions: TanStack Router. I haven’t shipped production code with it yet — but after watching how experienced teams talk about it, reading the docs, and comparing mental models, it’s clear the real story isn’t “React Router vs Next.js”. It’s about three different philosophies of building React apps.

React Router v7+ didn’t just get new APIs — it changed what React Router is. By merging Remix into React Router, the team effectively said:

“Routing isn’t just navigation — it’s where data, errors, and UI composition meet.”

For frontend devs, this feels surprisingly natural:

• Route loaders handle data fetching

• Actions handle mutations

• Errors are scoped to routes

• Nested routing finally means something

Coming from traditional React Router, the mental model is still recognisable. You don’t have to unlearn React — you just stop scattering data fetching across useEffect calls and custom hooks. That’s why this Reddit take resonates so much:

“React Router is still the default mental model most React devs understand, and v7+ has gotten a lot smoother with data APIs and nested routes.”

And I agree. Even if nested routing and loaders take time to “click”, once they do, the app structure feels cleaner and more intentional than many Next.js setups I’ve worked on

After longer projects, some issues show up:

• Route sprawl — lots of small files

• Loader duplication if you’re not disciplined

• Architecture quality depends heavily on the team

React Router gives you power, but not guardrails.

So… is Next.js dead? No. Not even close. Next.js still shines when:

• SEO and SSR are critical

• You want conventions over decisions

• You need edge rendering, static generation, or server components

• You want a battery-included platform

But from a frontend developer experience standpoint, it increasingly feels like:

• You’re learning Next.js, not React

• The framework often dictates architecture

• App Router abstractions can feel opaque

• Debugging server/client boundaries is non-trivial

That’s why many SPA-focused developers are stepping back and asking: “Do I really need all of this?” React Router Framework mode exists largely as an answer to that question.

TanStack Router isn’t trying to replace Next.js. It’s not even trying to replace React Router. It’s doing something more subtle — redefining routing as a typed, data-first system. From the official docs, TanStack Router is:

• Fully type-safe

• Framework-agnostic

• Designed to integrate deeply with TanStack Query

• Built around an explicit app-shell model

And that shows in how developers talk about it:

“If you want something more app-shell-oriented, TanStack Router has been gaining traction. It integrates nicely with TanStack Query, typed APIs, and file-based routing without Next.js. Slightly steeper curve, but a year in, you’ll probably appreciate its type safety and decoupled data layer.”

This is the key difference. React Router — UI-first routing. TanStack Router — Data-first routing.

With TanStack Router:

• Routes are strongly typed

• Params, loaders, and search state are compile-time safe

• Data fetching lives in TanStack Query, not the router itself

• The router orchestrates, it doesn’t own your data

This appeals less to beginners — but a lot to senior frontend engineers.

You’ll notice TanStack Router is recommended mostly by:

• Developers with large, long-lived SPAs

• Teams already invested in TanStack Query

• People burned by implicit magic

The trade-offs are clear:

• Steeper learning curve

• More upfront thinking

• Less “just works” feeling

But the payoff is:

• Excellent scalability

• Fewer architectural regrets

• Type safety that actually matters months later

It’s not hype — it’s maturity-driven adoption.

Nothing killed anything. What’s happening instead is specialisation:

React Router didn’t kill Next.js. TanStack Router didn’t kill React Router. They’re solving different pain points.

After using React Router Framework mode:

• I get why people are excited

• I like how explicit things feel

• I enjoy being closer to “just React”

After studying TanStack Router:

• I understand why experienced teams rave about it

• I can see myself appreciating it more over time

• I suspect it shines after month 6, not week 2

And Next.js?
Still great — just not always the right default anymore.

The real shift isn’t about tools. It’s about frontend developers reclaiming architectural choice. And honestly? That’s a good place for the React ecosystem to be.