Three React frameworks all shipped major versions in the last twelve months. TanStack Start reached 1.0. Next.js 16 made Turbopack the default and Server Components stable. React Router v7 absorbed Remix entirely.
You are five people starting a product. You have to pick one this week and live with it for two years.
Every comparison you find leads with a throughput number. That number is the least useful thing in the decision, and the benchmark behind it does not say what people quote it as saying. Here is the part that actually matters.
What is the real difference between these three?
Where the server boundary lives, and who decides it.
Next.js 16 is Server Components first. Every component is a server component until you write use client. The framework owns the boundary and you opt out of it. Server Components are stable, Turbopack is now the default bundler, and React 19.2 features are wired in.
React Router v7 is plain server rendering with no RSC. Loaders run on the server, components run in both places, and the mental model is the one Remix taught. It is the same library you already use for routing, with a framework mode bolted on top.
TanStack Start is type-first, with RSC opt-in and experimental. Server functions are RPC calls with validated input. The router carries end-to-end types from the loader to the component.
That is the fork. Not speed. Do you want the framework to decide where your code runs, or do you want to decide?
The question is not which framework is fastest. It is who owns the server boundary, you or the framework.
The benchmark everybody quotes, and why it settles nothing
You will see a figure passed around: TanStack Start at roughly 1,780 requests per second, about 25% ahead of React Router v7 and 40% ahead of Next.js.
I went to the primary source. It is a Platformatic benchmark run on an EKS cluster of four m5.2xlarge nodes, driven with Grafana k6 at a target of 1,000 requests per second. Three problems with using it to pick a framework:
Next.js did not lose, it failed. On v15.5.5 the benchmark reports average response times of 8 to 11 seconds and about 40% of requests failing. On a v16.2 canary it improved to a 431ms median with about 36% still failing. A framework dropping over a third of requests is not "40% slower". It is misconfigured, or being run in a way it was not built for. You cannot read a ranking off a run like that.
No caching was used at all. The authors say so, and justify it as mirroring personalised ecommerce. But caching is the entire architectural premise of Next.js, from Cache Components to fetch caching to the router cache. Removing it and reporting the result as a framework comparison is like benchmarking a database with the indexes dropped.
The publisher sells the runtime it won on. Platformatic makes Watt, the runtime all three frameworks were run under. That does not make the numbers dishonest, and the methodology is unusually well documented. It does mean this is not a neutral referee.
What the benchmark does support: TanStack Start held average responses under 13ms at 1,000 req/s with a 100% success rate, and React Router v7 also completed with zero failures. Both are comfortably fast enough. That is the real finding, and it is a much smaller claim than the one being repeated.
The comparison
| TanStack Start | Next.js 16 | React Router v7 | |
|---|---|---|---|
| Version and date | 1.0, March 2026 | 16, with 16.2 and 16.3 following | 7, Remix merged in |
| Server Components | Experimental, by TanStack's own docs | Stable and the default | None, and none planned |
| Server boundary | You choose, per function | Framework chooses, opt out with use client | Loaders and actions only |
| Type safety | End-to-end, loader to component | Conventional TypeScript | Generated route types |
| Server functions | RPC, validated input, GET and POST, middleware both sides | Server Actions, POST only, no middleware | Actions, web standard, server middleware |
| Client cache | Built in, staleTime and gcTime | fetch caching | None built in |
| Bundler | Vite or Rsbuild | Turbopack, default in 16 | Vite |
| Hosting | Deployment agnostic | Best on Vercel, self-hosting has rough edges | Adapters for most platforms |
| Hiring pool | Smallest | Largest by a wide margin | Large, Remix experience transfers |
| Pick it when | Types are the priority and you want no lock-in | You want RSC and the biggest ecosystem | You already use React Router and want SSR without a rewrite |
Sources: TanStack comparison docs, Next.js 16 release, Remix and React Router merge. Note that the first of those is written by TanStack about its own competitors, so read the rows it chose as well as the values.
Which one should a five person team actually pick?
Pick Next.js if you have no strong reason not to. The ecosystem is the largest, every problem you hit has been hit before, and hiring is easier than for the other two combined. Server Components are stable and Turbopack removed the build times that were the main complaint. The cost is that the framework makes architectural decisions for you and self-hosting is more work than the docs suggest.
Pick React Router v7 if you are already on React Router. This is the cheapest good decision on the list. You add server rendering, loaders and actions without a new dependency and without a rewrite. Remix teams migrate in hours because the APIs are the same. You get no RSC, which for most products is a feature rather than a loss.
Pick TanStack Start if types are the thing you care about most. End to end type safety from the loader through the server function into the component is genuinely different from writing types by hand around a framework that does not know about them. Take it seriously that RSC support is experimental in TanStack's own documentation, so do not pick it expecting to use Server Components in production this year.
Do not pick on throughput. All three handled 1,000 requests per second in the benchmark above once configured properly. Your product will not be slow because of this choice. It will be slow because of an N+1 query, an unoptimised image, or a 400KB bundle.
Your product will not be slow because of this choice. It will be slow because of an N+1 query and a 400KB bundle.
What each one costs you in two years
Next.js costs you portability. It runs best on Vercel and the self-hosting story has sharp edges. That is a real bill if you move later, and it is the most common complaint from teams who did.
React Router costs you ceiling. No RSC means when you do want to stream server-rendered components with zero client JS, the answer is a migration rather than a config change. For a lot of products that day never comes.
TanStack Start costs you maturity. Smallest community, fewest Stack Overflow answers, fewest people who have already hit your bug. v1.0 landed in March 2026, which is recent. You are trading ecosystem depth for type safety and independence.
None of those is wrong. They are just different bills, arriving at different times.
Common mistakes
Choosing on a benchmark you did not read. The headline number in this space comes from a vendor benchmark, run without caching, in which one framework failed over a third of its requests. Read the methodology before you let a number pick your stack.
Assuming TanStack Start gives you RSC. It is marked experimental in TanStack's own comparison page. If Server Components are a requirement, that requirement points at Next.js today.
Treating React Router v7 as "just the router". Framework mode is a full stack framework with loaders, actions, SSR and SSG. Teams dismiss it because the name sounds like a library and then rebuild half of it.
Optimising for a scale you do not have. A five person team choosing between 1,400 and 1,800 requests per second is choosing between two numbers it will not approach for years. Pick for the developer experience you will live in daily.
Underrating hiring. The framework you pick decides who can join your team next year without a ramp-up month. On a five person team, one bad month of onboarding costs more than any of these performance differences.
Key takeaways
- The real fork is where the server boundary lives: Next.js decides for you, TanStack Start and React Router let you decide.
- Next.js 16 makes Server Components stable and Turbopack the default bundler.
- TanStack Start reached 1.0 in March 2026, and its RSC support is still marked experimental by TanStack.
- React Router v7 is Remix merged in, so Remix apps migrate in hours and React Router apps gain SSR with no new dependency.
- The widely quoted throughput ranking comes from a vendor benchmark run with no caching, where Next.js failed 36 to 40% of requests. That is a configuration result, not a framework verdict.
- What the benchmark does support is that TanStack Start held sub-13ms averages at 1,000 req/s with a 100% success rate, and React Router v7 also finished with zero failures.
- For most five person teams the ranking is Next.js by default, React Router v7 if you are already on it, TanStack Start if type safety outranks ecosystem.
If you are picking a stack for a product rather than a side project, the framework is usually the easiest decision in the build and the one teams spend longest on. Web apps are one of the things we build, and the shape of the decision is normally hosting and hiring rather than rendering. For the agent side of a modern product, our comparison of the agent frameworks covers the same kind of trade in a different layer.