Next.js or TanStack Start

A founder asked me last week which framework to build on, and I caught myself about to say "Next.js" on reflex. Old habit. I stopped.

Because the honest answer is that both are right, and the wrong one only shows its face six months in, when the thing you skimped on becomes the thing you touch every single day.

Next.js and TanStack Start are both TypeScript-first React frameworks that render on the server and hydrate on the client. Same family. Different center of gravity. Next.js is built around React Server Components and a decade of ecosystem. TanStack Start is built around a router so type-safe it feels like the compiler is holding your hand from the URL bar all the way to the database.

I'll build in either. Happily. Here's how I actually pick.

Both are TypeScript to the core

Let me get the thing that doesn't decide it out of the way first.

Neither of these is the "safe" choice or the "risky" choice on types. Both are written in TypeScript, both infer aggressively, both catch you at compile time instead of at 2am. If a framework can't be TypeScript from the phone to the database, I'm not interested, and I've written about why that line is non-negotiable for me. Neither of these makes me cross it.

So the decision isn't which one is type-safe. It's where I want the type safety sharpest. That difference is most of this post.

Next.js wins on rendering and the ecosystem

Next.js bet early on React Server Components, and the bet paid off. If your product is content-heavy, if SEO pays your bills, or if you want big chunks of the page to render on the server and ship zero JavaScript to the browser, this is the smoother road. RSC is the reason. I laid out the mental model in the kitchen analogy post, and Next.js is where that model is most grown up.

Then there's the ecosystem, which is not a small thing. Deployment is a solved problem. Image handling, middleware, auth libraries, the whole aisle of tutorials someone on your team will Google at 11pm. It's all there and it mostly just works. The Next.js docs are the closest thing this space has to a default.

The cost? The App Router asks you to hold a lot in your head. Server components, client components, the boundary between them, caching that has surprised more than one senior engineer. Real power, with a learning tax attached.

TanStack Start wins on type-safe routing and data

Now the other side. This is the part people sleep on.

TanStack Start is built on TanStack Router, and the router is the backbone of the whole thing. Your routes are typed. Your search params are typed and validated. Your loaders run before the component renders and hand data down with full inference, no any anywhere in the pipe. Change a route param and every call site that got it wrong lights up red before you even save the file.

const route = createFileRoute('/posts/$postId')({
  loader: ({ params }) => fetchPost(params.postId),
  component: Post,
})
 
function Post() {
  const post = route.useLoaderData() // fully typed, no casting
  return <h1>{post.title}</h1>
}

For app-heavy products, dashboards, internal tools, anything where users live inside the interface and the URL carries real state, this feels genuinely different. The router stops being plumbing and starts being the spine. The TanStack Start docs show it off well.

The side-by-side

Here's the whole decision on one screen.

Read the last row twice. That's the one that actually predicts regret.

How I choose in practice

I ask one question first. Is the URL a table of contents, or is it the application?

If people arrive from Google, read something, and leave, the URL is a table of contents. Content sites, marketing pages, blogs, docs. Next.js, most days.

If people log in and live there, moving between views and holding state in the URL, then the URL is the application. Now I want the router that treats it that way, and TanStack Start earns the pick.

And when it's a genuine coin flip? I go with whichever the team already knows. A framework you understand beats a "better" one you're fighting at midnight. That's not a compromise. That's just respecting the constraint.

Frequently asked questions

Is TanStack Start production-ready?

It's newer than Next.js, so the surrounding ecosystem is thinner and you'll write a bit more yourself. The core is solid, and the router underneath it has been battle-tested in real apps for years. I'd ship a client tool on it today, and I have.

Does Next.js still make sense for a pure SPA?

It can, but you're carrying RSC machinery you might never use. For a heavily interactive app with no real SEO need, TanStack Start often fits the shape better. Match the tool to the traffic, not to the hype cycle.

Can I share types with a Hono backend in both?

Yes. Both are TypeScript end to end, so both play nicely with a shared types package and an RPC-style client. That safety across the wire is the whole reason I stay inside this stack.

Which has the gentler learning curve?

If you already think in React Server Components, Next.js feels natural. If you think in routes and loaders, TanStack Start clicks faster. Neither one is hard. They're just organized around different ideas about where the app lives.

Pick the one that fits the shape of the thing

There's no maximalist answer here, and anyone selling you one is selling, not advising. Next.js and TanStack Start are both excellent, both TypeScript to the bone, both frameworks I reach for without a second thought. The pick comes down to what your product actually is: a place people read, or a place people work. Get that one question right and the framework nearly chooses itself.

If you're staring at this decision for something real, tell me what you're building and I'll tell you honestly which way I'd lean.