Why TanStack Start Over Next.js

Next.js paved the way for full-stack React development. It deserves enormous credit for making server-side rendering accessible, establishing conventions that shaped how we think about React applications, and proving that the React ecosystem could compete with Rails-style productivity. Without Next.js, the modern React landscape would look very different.

But when I was choosing a framework for Eden Stack, I chose TanStack Start. Here's why.

The Self-Hosting Reality

Let's start with the elephant in the room: Next.js is notoriously difficult to self-host outside of Vercel.

This isn't FUD. It's documented reality. According to BuiltWith data, while 34% of Next.js sites run on Vercel, up to 80% of large enterprise organizations do not use Vercel or similar FEaaS providers. Why? Because enterprises have their own infrastructure requirements — Azure, AWS, on-premise data centers, compliance mandates.

And when you try to self-host Next.js at scale, things break in ways that aren't immediately obvious:

• Distributed caching fails across multiple replicas
• Image optimization requires additional infrastructure
• Incremental Static Regeneration needs shared storage that isn't documented
• Environment variables behave differently than on Vercel
• Container deployments have notorious issues (just search "Next.js Azure App Service container" and count the Stack Overflow questions)

As David Höck wrote in his comprehensive guide on self-hosting Next.js at scale: "Self-hosting Next.js in production is fundamentally different from clicking 'deploy' on Vercel. When you're dealing with horizontal scaling, multiple replicas, and enterprise-grade requirements, the default Next.js setup breaks down in ways that aren't immediately obvious."

TanStack Start is Deployment-Agnostic

TanStack Start was designed from the ground up to run anywhere: Node, Bun, Deno, Cloudflare Workers, Netlify, AWS Lambda, Azure Functions, your own Kubernetes cluster. It doesn't matter.

There's no "golden path" that only works on one platform. The framework compiles to standard JavaScript that runs in any environment supporting your chosen runtime. No special adapters, no undocumented environment variables, no surprises when you move from development to production.

For Eden Stack, this was non-negotiable. A boilerplate that only works well on one hosting provider isn't a foundation — it's a constraint.

Type Safety That Actually Works

Both frameworks claim type safety, but the approaches differ fundamentally.

Next.js provides type safety through generated types — you write code, Next.js infers types, and you hope everything lines up. It works, mostly, until it doesn't. The App Router introduced complexity that made type inference less predictable.

TanStack Start offers fully type-safe routing at compile time. Routes, loaders, search params, path params — everything is inferred and validated by TypeScript before your code runs. Combined with Eden Treaty for API calls, you get end-to-end type safety from database to UI without any code generation steps.

// TanStack Start: Types are inferred at the route level
export const Route = createFileRoute('/users/$userId')({
  loader: async ({ params }) => {
    // params.userId is typed as string
    return await getUser(params.userId)
  },
})

The Complexity Question

Next.js has grown increasingly complex. The App Router, React Server Components, Server Actions, partial prerendering, the use hook, cache(), unstable_cache(), various rendering strategies — the mental model required to work effectively with modern Next.js is substantial.

Some of this complexity is genuinely powerful. RSC can enable impressive performance optimizations. But it comes at a cost: developer experience, debugging difficulty, and the constant question of "am I using this correctly?"

TanStack Start takes a different approach. It uses full-document SSR with full hydration — a simpler model that's easier to reason about. There's no magic. No opaque server/client boundary confusion. The tradeoff is that you don't get RSC's granular streaming, but you gain clarity and predictability.

For a boilerplate meant to help developers ship quickly, I'd rather give them a foundation they can understand completely than one with hidden complexity that surfaces at the worst times.

What About AI and Training Data?

A common argument for Next.js: it's more popular, so AI coding tools have more training data for it.

I'm skeptical this matters much anymore. Modern AI agents don't just rely on pre-trained knowledge — they actively research documentation while working. Claude can read TanStack's docs. Cursor can search the repo. The quality of documentation matters more than the quantity of Stack Overflow posts.

TanStack's documentation is exceptional. It's fresh, well-organized, and designed for both humans and AI parsing. The patterns are consistent and explicit. When an AI assistant works with TanStack Start, it can reason about the codebase clearly because the framework itself is clear.

When Next.js Still Makes Sense

I'm not saying Next.js is bad. It's excellent for:

• Vercel deployments — the integration is genuinely best-in-class
• Content-heavy sites — RSC shines for streaming lots of static content
• Teams with Next.js expertise — switching frameworks has real costs
• Projects already using it — migration rarely makes sense mid-project

If you're building a marketing site that will live on Vercel, Next.js is probably the right choice.

Why Eden Stack Uses TanStack Start

For a production-ready template that developers will use to build real businesses, the calculus was clear:

1. Deployment flexibility — You shouldn't be locked to one hosting provider
2. Type safety — End-to-end inference without code generation
3. Simplicity — A mental model you can fully understand
4. AI-friendly — Great docs, explicit patterns, no magic

TanStack Start + Elysia + Eden Treaty gives us type-safe full-stack development that works anywhere. That's the foundation Eden Stack is built on.

This post reflects my opinions after building production applications with both frameworks. Your mileage may vary, and technology decisions should be based on your specific requirements.