TanStack Start Has My Attention

This is not a "Next.js is dead" post. I still use Next.js. I still love it. But TanStack Start is doing some things differently that genuinely excite me as someone who cares a lot about developer experience.

The server and client confusion is gone

Building anything serious in Next.js App Router means eventually hitting the wall. Which components are server components? Can I use a hook here? Why is this context not working? The mental model is powerful once it clicks, but the line between server and client is blurry in ways that catch me off guard.

TanStack Start is client-first in the sense that I just write regular React. No use client at the top of every file, no stopping to ask whether a hook is allowed here, no mental overhead about which component runs where. Everything SSRs by default and hydrates on the client automatically. I write the same way I always have and the framework handles the rest. TanStack Start does support React Server Components now, but they are opt-in and treated as a data optimization, not the foundation everything is built around. That is the opposite of Next.js App Router, where RSCs are the default and client components are the exception.

The type safety is end to end without the extra tools

I love TypeScript. Always have. Writing JavaScript feels like guessing half the time.

Next.js is typed, but it gets shaky at the network boundary. If I want truly safe data fetching I end up pulling in tRPC and Zod on top, which are both solid, but now I am managing three things instead of one. TanStack Start handles that from the start, and the reason it works so well is that it is built directly on TanStack Router. Because the routing engine owns both the server data fetching layer and the client rendering layer, TypeScript tracks types seamlessly across the entire request lifecycle.

In practice that means a few things. When a route loader returns data, useLoaderData() automatically infers the exact type. If I change a field on the server, my component will throw a TypeScript error immediately. Search params are defined as schemas right in the route config, so I cannot navigate to a route with a missing or wrong query param without the build catching it. And when I wrap a database call in createServerFn, it creates a type-safe RPC channel automatically. The input and return types are preserved on the client with no extra wiring.

Vite over Turbopack

I have used both. Vite is fast, stable, and already familiar from other projects. But the real story here is not the build speed.

Next.js and Turbopack are deeply tied to Vercel's infrastructure. Image optimization, edge routing, caching, which a lot of it is built around Vercel's proprietary setup. That works fine until I want to self-host on Docker, move to AWS, or switch providers. Then it gets messy fast.

TanStack Start pairs Vite with Nitro as the server bundle engine. Nitro is platform-agnostic by design, so switching where I deploy is just changing one preset in my config.

// vite.config.ts
export default defineConfig({
  server: {
    preset: 'cloudflare-workers', // Switch to 'vercel', 'netlify', 'node-server', or 'bun' instantly!
  },
})

No rewrites, no fighting the framework. Just ship it wherever I want.

Now for the honest part

TanStack Start is new. That is exciting and also a real tradeoff.

The framework is still maturing, which means I will run into bugs that do not have Stack Overflow answers yet. Worse, the AI tools I rely on will not know it well. I have leaned on Claude and ChatGPT enough to know that a framework with thin training data is a framework where I am on my own more often. That is fine if I am comfortable digging through source code and GitHub issues, but it is something to factor in.

Caching is another one. Next.js handles a lot of it with its built-in caching model. In TanStack Start I am doing more of that work myself. I actually like the control, but I would be lying if I said it adds zero overhead.

And because the framework is client-first, I have to be more deliberate about security. Sensitive logic that Next.js server components keep safely on the server needs conscious handling here.

Where I land

I am not switching. I am adding.

Next.js is still my default for content-heavy apps, SEO-critical projects, and anything that benefits from the ecosystem around it. That is not changing.

But for apps where I want tight TypeScript guarantees, a clear mental model between server and client, and a Vite-powered dev experience, TanStack Start is going to get more of my time. f you want to see it in action, the source is on GitHub and the live demo is here.

Sometimes the right tool is not a replacement. It is just a better fit for the thing I am building next.