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 = 1.x stable (released May 2026). The official TanStack site still labels it "RC" in some nav elements, but the npm packages and GitHub releases are on stable 1.x semver. 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.

💡 Furin note — defer() is optimized for SSR. SSG and ISR routes support it, but deferred Promises resolve synchronously during the render pass (no streaming benefit).

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: May 9, 2026. Sources: Next.js 15 docs, TanStack Start 1.x stable docs, Furin source code, @tanstack/react-start GitHub (packages/react-start, start-server-core, start-plugin-core).