Web: Next.js is the safe default; choose TanStack Start when you want a less-opinionated, Vite-native full-stack alternative (Server Functions stable; RSC opt-in and still experimental; Start itself is v1 RC). RN/universal: Expo Router.
content/marketing site → Astro (ship less JS)
Cloudflare-first stack → RedwoodSDK
want minimal RSC, no lock-in → Waku (still beta)
evaluating Vinext → not production-ready; don't bet on it yet
Options & tradeoffs
the field considered — and why each one isn’t the default here
option
tradeoff
evidence
Next.js (16.x)
most-used; App Router + RSC + Server Actions; Adapter API STABLE in 16.2 (co-designed w/ OpenNext/Netlify/Cloudflare — verified adapters: Vercel + Bun shipped, others in dev) settles off-Vercel portability; frequent security patches
45.9M/wk · ships in 5/34
TanStack Start
Vite-based (Rsbuild 2 also supported since 2026-06); RSC support EXPERIMENTAL (into early v1), SSR, Server Functions; deliberately omits Server Actions for security; less opinionated than Next
15.4M/wk · ships in 1/34
React Router 7 (framework mode) / Remix
Remix merged into React Router 7; full-stack loaders/actions; Remix 3 is a separate JSX-component pivot away from RR
Expo Router
the RN/universal meta-framework; SDK 56 decoupled from React Navigation; web SSR (alpha)
Astro / Waku / RedwoodSDK
Astro = content/islands; Waku 1.0-beta = minimal RSC — its SLICES (reusable components w/ independent render config; lazy slices ≈ Astro server islands, mixable across static/dynamic pages) are its distinctive feature; RedwoodSDK 1.0 = Vite+RSC+Cloudflare
3.9M/wk
Vinext (Cloudflare)
Vite-based Next.js rebuild; 1.0.0-beta (2026-07-04, verified vs npm) drops the experimental label — maturing, but AI-generated origins + the security issues Vercel flagged warrant re-verification before any production bet
npm weekly downloads (from the corpus's last signals run): next 45.9M · @tanstack/react-start 15.4M · astro 3.9M · waku 19k
Verified notes
Distinct from routing (RB-E-NAV): these own SSR/RSC/data/build. Context-key by hosting target + how much RSC you actually need. UPDATE 2026-07-10 (React Weekly, verified): Next.js Adapter API went STABLE in 16.2 with a shared public test suite + an Ecosystem Working Group — the durable answer to "can I run Next off Vercel"; TanStack Start's RSC support is explicitly EXPERIMENTAL into early v1 (don't sell Start as an RSC-parity Next alternative yet); adoption signal — Lovable (the largest AI app-builder) defaults new projects to TanStack Start SSR since 2026-05. CHALLENGE-PASS CAVEATS (2026-07-10, fetch-verified): Start's npm download surge (~60x since Jan 2026) is inflated by Lovable's platform CI — raw downloads ≠ team adoption; Next held flat (~160-175M/mo). And Next security releases DON'T BACKPORT: the May-2026 release (13 advisories, 7 High, incl. upstream RSC CVE-2026-23870) patched only 15.5.18/16.2.6 — choosing Next commits you to tracking latest minors. UPDATE (2026-07-20, verified vs the first-party program post): security releases are now SCHEDULED — monthly advance notice on the Next.js blog (expected date + highest anticipated severity); the first one landed 2026-07-20 (verified vs the release post): 4 High + 5 Medium CVEs, patched in v16.2.11 (Active LTS) and v15.5.21 (Maintenance LTS) only — the no-backport rule above still holds, the DATE is what became predictable. Ad-hoc patches remain for in-the-wild exploits. Predictable upgrade windows soften (not remove) the track-latest-minors commitment. Stress-tested 2026-07-10 (WEAKENED → caveats applied; the Next-default and the how-much-RSC context-key both SURVIVED the migration-wave attack). LANDSCAPE (2026-07-16 back-audit, verified vs the Vercel post): Vercel and Shopify are REBUILDING HYDROGEN together — Shopify's React meta-framework consolidating toward the Vercel/Next stack rather than remaining an independent Remix-lineage framework; Waku's slices fact verified vs Daishi Kato's first-party post.
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
Argues RSC is a serialization protocol that enables both server-owned and client-owned trees, contrasting TanStack Start's inversion-of-control with Next.js's server-owned model. The durable mental model for reasoning about RSC across frameworks.
First-principles RSC tutorial grounded in TanStack Start's explicit API (createServerFn, renderServerComponent), contrasted with Next.js's implicit model, with honest use-case scoping and bundle-size results.
Migration postmortem — 200+ routes off Next.js onto Vite + TanStack Start (10min→<2min builds), with the reasoning for when a client-centric app outgrows a server-first meta-framework. A concrete decision case study.
The mental model for the use-client boundary — it does NOT disable SSR — plus its three real costs (bundle, hydration, fetch waterfalls), with measured comparisons and the server-component-as-prop technique. Durable RSC fundamentals.
How Next.js closes RSC's biggest UX gap — slow navigations — with Cache Components + a per-route Stream/Cache/Block choice and Partial Prefetching (one reusable per-route shell instead of a prefetch per link). The durable mental model for server-driven-but-instant navigation; covers a facet the other RSC readings don't. Gated behind cacheComponents/partialPrefetching flags (16.3 Preview, not yet stable — verify before quoting as GA).
The reversal of the adoption post this entry already cites in sources — read them as a pair. RSC did work: moving markdown + Shiki highlighting to the server cut client JS by ~153KB gzipped on blog/docs pages, took /blog/react-server-components from Lighthouse 52→74 and TBT 1,200ms→260ms. The reversal argument is that the win came from KEEPING A HUGE DEPENDENCY OUT OF THE BROWSER, not from the architecture: once they replaced the 358KiB markdown/highlighting stack with small purpose-built packages (~27KiB transferred, only ~18–19KiB more than the RSC version), plain SSR + server functions held the performance and the RSC machinery — bundler config, serialization boundaries, special files, runtime-boundary rules — was left with nothing to pay for. The honest context-key for 'how much RSC do you actually need': measure whether your case is a dependency problem before you make it an architecture problem.
A systematic map of the whole rendering spectrum — CSR, SSG, ISR, SSR, streaming SSR + Suspense, RSC, islands, signal-based fine-grained reactivity, Qwik resumability, and Next 16.3 instant navigations — organized around ONE durable question: the gap between when a page LOOKS ready (HTML painted) and when it WORKS (JS hydrated/executing). Each strategy is a different trade on that window — ship less JS (islands/RSC), execute it faster (signals), or skip execution (resumability). The mental model that turns 'which meta-framework / rendering mode' into a reasoned choice instead of a checklist; the framing behind this entry's context-keys.
Depth (in-domain rules) is owned by the engineering-principles skill — this entry is selection breadth.
The full explanation
The reviewed long-form essay behind this entry — the why, not a how-to. Also on GitHub.
About meta-frameworks (full-stack React)
Diataxis: Explanation. This page builds understanding of the meta-framework choice.
It is not a tutorial: the candidate list and one-line tradeoffs live in the index entry
RB-E-META-FRAMEWORKS; client-side routing is RB-E-NAV; the RSC primitive itself is
RB-E-REACT-CORE; Server-Function security is RB-E-SECURITY. Read this for the why.
What a meta-framework actually is (and isn't)
A router decides which screen. A meta-framework decides where your React runs: it owns
SSR/RSC, data fetching, the server boundary, and the build. That's the category. So the
question is never "Next or not" in the abstract — it's "how much server do I actually
need, and where am I hosting it?" Those two axes — amount of server (static site → SPA →
SSR → full RSC) and hosting target (Vercel / Cloudflare / self-host / none) — sort the
whole field.
The mental model: who owns the component tree?
The clarifying lens for 2026 is RSC-as-protocol, not RSC-as-architecture. React Server
Components are a serialization format (the Flight protocol) for streaming a component tree;
they do not dictate who owns that tree. Two camps fall out:
Server-owned (Next.js App Router). The tree starts on the server; client components
are the islands. Opinionated, integrated, batteries-included — Server Actions are the
mutation path.
Client/router-owned (TanStack Start). The app is router-first and isomorphic; RSC is
available as a protocol you opt into, SSR and Server Functions are explicit, and it
deliberately omits Server Actions (a deliberate security posture — see RB-E-SECURITY).
Neither is "more correct." Server-first minimises client JS and is great when the server is
always there; router-first keeps the client app primary and the server optional. Knowing
which ownership model you want predicts which framework will feel natural.
The default, and why
Web: Next.js is the safe default; choose TanStack Start when you want a
less-opinionated, Vite-native RSC stack. React Native / universal: Expo Router.
Next.js is the default for the boring-but-correct reason: it is the most-used, most-hired-for,
most-documented full-stack React framework, and its App Router + RSC + Server Actions cover
the common product app. TanStack Start is the considered alternative — Vite-native,
router-first, RSC-as-protocol — for teams who feel Next's opinions as friction and want to
own more of the stack. For React Native / universal, Expo Router is the meta-framework;
the web frameworks here don't apply to native.
The landscape, and when each one wins
Next.js — the incumbent. Wins on ecosystem, hiring, hosting (first-class on Vercel,
adapters elsewhere), and the most complete RSC + Server Actions story. Cost: opinions, and a
steady security-patch cadence around the server surface.
TanStack Start — Vite-based, type-safe-router-first, RSC and Server Functions as explicit
APIs, Server Actions deliberately omitted. Wins when you want a less-opinionated, Vite-native
stack and tight control of the client/server seam.
React Router 7 (framework mode) / Remix — Remix merged into React Router 7; full-stack
loaders/actions for teams already living in React Router. (Remix 3 is a separate
JSX-component pivot, distinct from this lineage.)
Expo Router — the RN/universal meta-framework: file-based routing, SDK-56-era decoupling
from React Navigation, web SSR still maturing. The way a React Native app becomes "full-stack
web" from one tree.
Astro / Waku / RedwoodSDK — pick by hosting + how much RSC: Astro for content/marketing
(ship the least JS, islands only); Waku for minimal RSC with no lock-in; RedwoodSDK for a
Cloudflare-first Vite+RSC stack.
Vinext — a Vite-based Next.js rebuild; AI-generated and early, with flagged security
issues and thin real test coverage. Not a production bet yet — interesting as a signal,
not a choice.
Tradeoffs and failure modes to name out loud
Buying more server than you need. A marketing site rendered through a full RSC
framework is over-built; Astro (or a static export) ships a fraction of the JS. Start from
"how much server," not "which framework everyone uses."
Server Functions are an API boundary in disguise. Compiler-generated function IDs and
the dissolved network seam are real attack surface and a real version-skew hazard across
rolling deploys; treat them with API discipline (RB-E-SECURITY).
Conflating routing with the framework.RB-E-NAV is a subset of what these own; if
all you need is client routing, you may not need a meta-framework at all.
Lock-in by hosting assumption. Some stacks assume a specific host (Vercel, Cloudflare);
fine if you're there, a migration cost if you're not. Make it a conscious axis.
How it interacts with the rest of the stack
Routing (RB-E-NAV). Meta-frameworks subsume routing and add the server; the standalone
routers in RB-E-NAV are for when you don't want that.
React core (RB-E-REACT-CORE). RSC, Server Functions, and use() are React primitives;
this entry is about the frameworks that productise them.
Data (RB-E-DATA). With a server framework you often fetch in RSC and skip a client
cache; without one, TanStack Query owns server-state. The framework choice shifts where the
data layer lives.
Cross-platform (RB-E-CROSSPLATFORM). Expo Router (+ Solito) is how routing and some
data-loading get shared web↔native.
Security (RB-E-SECURITY). The RSC/Server-Function server surface is where the
framework-specific CVEs live; patch cadence is part of the choice.
In one paragraph
A meta-framework is "where your React runs on a server," so choose by how much server you
need and where you host, using the who-owns-the-tree lens: Next.js (server-owned,
opinionated, the safe default) vs TanStack Start (router-first, RSC-as-protocol, Vite-
native, Server-Actions-free). Drop to Astro for content, Expo Router for RN/universal,
and treat Vinext as not-yet-production. Don't buy more server than the app needs, and
remember Server Functions are an API boundary with real security and deploy-skew implications.
react-brain