Next.js vs TanStack Start vs Furin

Choosing a React meta-framework is not about picking the "best" one — it is about picking the one whose trade-offs match your constraints. This page compares Next.js (App Router), TanStack Start, and Furin across every dimension that matters for production decisions.

Disclaimers

• Next.js = App Router (stable), not Pages Router.
• TanStack Start = RC (1.x, pre-GA). The official TanStack site labels it "RC / preparing for 1.0". Server functions are stable; RSC is experimental and excluded.
• Furin = latest stable. Where a feature is planned but not shipped, we say so explicitly.
• This comparison is maintained by the Furin team. We flag our own limitations with ⚠️ and our advantages with 💡 so you can verify independently.

At a glance

Architecture & Runtime

💡 Furin advantage — Single-process dev eliminates the "two servers out of sync" class of bugs. HMR, SSR, and API routes share the same Bun runtime and module graph.

⚠️ Furin limitation — Bun-only means you cannot deploy to standard Node.js containers without switching runtimes. Docker with oven/bun is the recommended path.

Build System

💡 Furin advantage — compile: "embed" produces a single self-contained binary with all assets baked in. This is unique among React meta-frameworks and ideal for CLI tools, desktop apps, or air-gapped deployments.

⚠️ Furin limitation — The Bun bundler ecosystem is younger than Vite/Rollup. Some advanced transforms may require writing a custom BunPlugin.

Render Modes

💡 Furin advantage — ISR is implemented with stale-while-revalidate semantics, ETags, and Cache-Tag headers out of the box. No platform-specific adapter required.

⚠️ Furin limitation — No RSC means every component in the tree is shipped to the client. For apps with heavy server-only logic (data transforms, heavy libraries), this increases bundle size compared to Next.js App Router.

Dev DX (Developer Experience)

💡 Furin advantage — Built-in structured logs for every cache hit/miss/stale make debugging caching behavior straightforward in both dev and production.

⚠️ Furin limitation — The dev error overlay is less polished than Turbopack or Vite. Stack traces are accurate but formatting is basic.

Caching

💡 Furin advantage — Built-in CDN semantics (Cache-Tag, s-maxage, stale-while-revalidate, must-revalidate) without platform lock-in. The setCachePurger() hook works with any CDN (Cloudflare, Fastly, custom).

⚠️ Furin limitation — No data cache means ISR background revalidations re-run all loaders from scratch, even if the underlying data has not changed. Next.js unstable_cache can avoid this. A data cache layer is planned.

⚠️ Furin limitation — In-memory cache is lost on process restart. For Docker deployments, this means every deploy or crash wipes the ISR cache. A filesystem-backed cache adapter is planned.

Routing & Layouts

💡 Furin advantage — Layouts are Elysia routes with loaders, so you get typed params/query and middleware at every nesting level. The _route.tsx file is both a layout and a route boundary (error + not-found).

⚠️ Furin limitation — No route groups, parallel routes, or intercepting routes. These are App Router-specific advanced patterns. If you need them, Next.js is the better choice.

Data Loading

💡 Furin advantage — Loaders are standard async functions with TypeBox schemas for params/query. No magic conventions: what you see in createRoute() is what gets validated at runtime.

⚠️ Furin limitation — No server actions. Mutations must go through Elysia API routes (/api/*) or external endpoints. This is explicit but more verbose than Next.js "use server".

Type Safety

💡 Furin advantage — createRoute() is the single source of truth for params, query, and loader types. The generated furin-env.d.ts gives autocomplete on <Link> without any runtime overhead.

⚠️ Furin limitation — No equivalent to TanStack Query for client-side data fetching. If you need complex client caching, deduplication, and background refetch, you must bring your own data library.

Deployment

💡 Furin advantage — The compiled binary (compile: "embed") is a unique deployment artifact. One file, no node_modules, no Docker image. Copy it to a server and run it. This is ideal for internal tools, offline environments, or simple VPS setups.

⚠️ Furin limitation — Platform adapters (Vercel, Cloudflare) are not yet implemented. If you need serverless/edge deployment today, Next.js or TanStack Start are better choices.

When to choose which

Choose Furin if...

• You are already using Bun and want to stay in a single runtime.
• You want one process for dev and prod (no separate bundler + server).
• You need an embeddable binary (CLI tools, desktop apps, air-gapped deployments).
• You prefer Elysia as your HTTP framework (typed, chainable, fast).
• You want CDN-ready cache headers without platform lock-in.

Choose Next.js if...

• You deploy to Vercel (native integration, edge functions, analytics).
• You need React Server Components (zero client JS for server-only UI).
• You need Server Actions for mutations without API routes.
• You use advanced routing (parallel routes, intercepting routes, route groups).
• You need the largest ecosystem (plugins, examples, hiring pool).

Choose TanStack Start if...

• You want a library-first approach (bring your own UI, styling, state).
• You prefer Vite and the Rollup ecosystem.
• You need TanStack Router features (nested routing, search param validation, breadcrumbs).
• You want TanStack Query integration out of the box.
• You prefer H3/UnJS for server primitives.

Summary table

Last verified: April 23, 2026. Sources: Next.js 15 docs, TanStack Start RC docs (v1.x, pre-GA), Furin source code, @tanstack/react-start GitHub (packages/react-start, start-server-core, start-plugin-core).