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). Picking Next commits you to tracking its latest minors, because security fixes do not backport. RN/universal: Expo Router.
content/marketing site → Astro (ship less JS)
Cloudflare-first stack → RedwoodSDK
want minimal RSC, no lock-in → Waku (RC as of 2026-09-18; 1.0-stable tripwire wired)
full-stack loaders/actions on an existing React Router app → React Router 8 framework mode (RB-E-NAV owns its security floor)
evaluating Vinext → reached stable 1.0 with claimed production customers; still re-verify independently before your own production bet (AI-generated origins, unresolved security concerns Vercel raised)
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. Security fixes land only on the latest minors; 16.4.0 (2026-10-06, verified vs npm + the 16.4 post) is latest and makes Cache Components the recommended model. See note: NEXT SECURITY, NEXT 16.4
76.9M/wk · ships in 5/34
TanStack Start
Vite-based (Rsbuild 2 also supported since 2026-06); SSR + Server Functions; RSC support EXPERIMENTAL into early v1; deliberately omits Server Actions for security; less opinionated than Next. Still v1 RC (verified vs tanstack.com/start 2026-09-24). Hosting no longer separates it from Next. See note: TANSTACK START
16.6M/wk · ships in 1/34
React Router 8 (framework mode) / Remix
Remix merged into React Router; full-stack loaders/actions. Remix 3 is a separate JSX-component pivot away from RR (see note: REMIX 3). RB-E-NAV owns React Router versions and its security floor.
Expo Router
The RN/universal meta-framework; decoupled from React Navigation since SDK 56; SDK 58 (beta) makes data loaders, SSR and middleware stable with no experimental flags (RB-E-NAV owns the detail).
Astro / Waku / RedwoodSDK
Astro = content/islands; Waku 1.0-rc (rc.2 2026-09-28, verified vs npm) = minimal RSC whose SLICES are its distinctive feature (see note: WAKU); RedwoodSDK 1.x = Vite+RSC+Cloudflare.
7.9M/wk
Vinext (Cloudflare)
Vite-based Next.js rebuild; reached STABLE 1.0 (2026-09-28, verified vs npm + the Cloudflare post) — Pages Router support added (was App Router only), >99% compat on customer-requested features, 'cache warming' moves prerendering from build time to Cloudflare's network, two-command migration (vinext check && vinext init). Cloudflare states production customers on high-traffic apps; still re-verify the AI-generated origins + the security issues Vercel flagged before your own production bet.
npm weekly downloads (from the corpus's last signals run): next 76.9M · @tanstack/react-start 16.6M · astro 7.9M · waku 44k
Verified notes
A meta-framework owns SSR/RSC, data loading, the server boundary and the build; routing alone is RB-E-NAV's. Context-key the pick by hosting target and by how much RSC you actually need. Next.js stays the default because it is the most-used and most complete RSC + Server Actions stack, and the stable 16.2 Adapter API (with a shared public test suite and an Ecosystem Working Group) is the durable answer to "can I run Next off Vercel". Its cost is a security cadence that only patches the latest minors. TanStack Start is the considered alternative, but its RSC is experimental, so do not sell it as an RSC-parity Next replacement.
NEXT SECURITY (verified vs the Next.js security-program post, the July/August/September release posts and GHSA-vcvr-r3jv-pc5j): fixes do not backport. The May 2026 release (13 advisories, 7 High, incl. upstream RSC CVE-2026-23870) patched only 15.5.18/16.2.6. Since 2026-07-20 releases are scheduled monthly with advance notice on the Next.js blog (expected date + highest anticipated severity); ad-hoc patches remain for in-the-wild exploits. JULY (2026-07-20): 4 High + 5 Medium, patched in 16.2.11 (Active LTS) and 15.5.21 (Maintenance LTS) only. AUGUST: pre-announced 2026-08-20 as one critical, shipped 2026-08-25, a day early, after a second critical was found — two unauthenticated RCEs patched in 16.3.3/15.5.24: CVE-2026-75604 (GHSA-p293-qw3h-jr36, Windows-hosted servers only, Pages Router + App Router without Cache Components, no workaround) and GHSA-2xp9-vwfh-vxw4 (attacker-controlled AVIF in the Image Optimization API, upstream libheif via sharp; the patch disables AVIF optimization until upstream propagates, a fix that removes a feature). SEPTEMBER: an out-of-band release on 2026-09-22 (16.3.6 Active LTS / 15.5.26 Maintenance LTS) for CRITICAL GHSA-vcvr-r3jv-pc5j (CVSS 9.5), RCE in the Node next/og ImageResponse via improper escaping in Satori's SVG output. Affected: >=16.2.0 <16.3.6, and only where attacker-controlled values reach SVG content, attributes or styles (if you cannot upgrade, don't pass them); the Edge ImageResponse is not affected, and 15.x is not vulnerable (15.5.26 is hardening only). The scheduled September release (16.3.7, 2026-09-29) was a bug-fix-only build with no security content; the actual scheduled fixes shipped 2026-09-30 as 16.3.8 / 15.5.27 and covered 7 of the originally-announced 9 vulnerabilities — 1 High: CVE-2026-94483/GHSA-cjq9-62q9-8jv4 (SSRF via an allow-listed remote URL in Image Optimization; unaffected if images.remotePatterns is unconfigured); 5 Medium: CVE-2026-94543/GHSA-4jqv-mc3x-m676 (self-hosted Pages Router SSG/ISR cache-entry cross-route substitution), CVE-2026-94484/GHSA-mcj8-r9mp-w47p (root catch-all + SSG/ISR cache poisoning from one unauthenticated request → cross-user content + persistent DoS), CVE-2026-94485/GHSA-f87g-xv8r-7p7x (App Router metadata image routes ignore dynamicParams on webpack builds; Turbopack unaffected), GHSA-h694-7cp9-m8p3 (nested 'use cache' functions mis-key on a root param, leaking non-attacker-controlled cached content across param values), and CVE-2026-94544/GHSA-3w37-wq28-93x7 (pending 'use cache' fills leak Draft Mode content into regular/persisted responses when Cache Components + Draft Mode previews overlap); 1 Low: CVE-2026-94486/GHSA-39w2-rjm5-chcv (next dev's MCP endpoint lacks origin checks, letting a malicious site read disk paths/source snippets/routes/logs off a developer's machine). The remaining 2 (1 Critical, 1 High) were POSTPONED for upstream coordination with no committed date. Consequence: the schedule makes dates predictable but has already slipped early, gone out-of-band, split across three releases (16.3.6/.7/.8) inside eight days, and still has a critical outstanding — budget for tracking latest minors continuously, not for a monthly slot.
NEXT 16.3 (2026-08-03, verified vs nextjs.org/blog/next-16-3 and npm): 16.3 is stable. Instant navigations (Cache Components + Partial Prefetching) remain opt-in via the cacheComponents and partialPrefetching flags, which the team plans to make default in a future major.
NEXT 16.4 (2026-10-06, verified vs nextjs.org/blog/next-16-4 and npm `latest` 16.4.0): the team now recommends Cache Components "as the best choice for every Next.js app", create-next-app enables it by default, and it "will become the default in Next.js 17" (the model = cacheComponents + partialPrefetching). New: `export const ensureStatic = 'navigation' | 'prefetch' | 'shell'` fails the build if dynamic content enters a route or layout; `await navigation()` / `await prefetch()` from next/cache defer cached work out of a prefetch or shell. `next upgrade --agent` drives an agent upgrade, and experimental.agentUpgrade nudges during dev/build ('security' is the default policy: remind on upgrades that fix vulnerabilities in the installed version). Ships React 19.3; Turbopack disk cache 20-25% smaller. → New Next apps should start on Cache Components; existing apps should plan the migration before 17 rather than at it. The 16.4 post names no security fixes; the two vulnerabilities postponed from September (NEXT SECURITY) are not recorded as fixed.
TANSTACK START (2026-07-10, verified vs React Weekly; 2026-09-08 vs the TanStack–Vercel partnership post): RSC is experimental into early v1. A critical reflected-XSS CVE (CVE-2026-102989, 2026-09-30) was patched at @tanstack/react-start ≥1.168.60 — floor and detail owned by RB-E-SECURITY. Lovable, the largest AI app-builder, defaults new projects to Start SSR since 2026-05, and that inflates Start's npm surge (~60x since Jan 2026) through platform CI, so raw downloads are not team adoption; Next held flat (~160-175M/mo). Vercel became a Gold TanStack partner on 2026-09-08 with a first-party Start deployment guide (Git deploys + preview URLs), so Start and Next both run there and hosting is no longer a differentiator.
REMIX 3 (2026-09-01, verified vs the Remix blog; npm 2026-09-24): a release candidate for the separate-from-React-Router Remix 3 — one `remix` package bundling database management, schema validation, a type-safe router, an unbundled asset server and a new UI runtime (3.0.0-rc.3 on npm's next tag, 2026-09-18). The post commits to releasing on 2026-10-02 at Remix Jam and separately lists what remains before they would call it stable (bug cleanup, security audits, early-adopter feedback, docs): 2026-10-02 is a ship date, not a stability guarantee. Not an option row: no production track record.
WAKU (verified vs Daishi Kato's post and npm): slices are reusable components with independent render config; lazy slices resemble Astro server islands and mix across static and dynamic pages. 1.0.0-rc.2 (2026-09-28, verified vs npm; no notable changes surfaced over rc.1).
LANDSCAPE (2026-07-16, verified vs the Vercel post): Vercel and Shopify are rebuilding Hydrogen together, moving Shopify's React meta-framework toward the Vercel/Next stack rather than an independent Remix-lineage framework.
RB-E-NAV owns routing and the React Router security floor; RB-E-SECURITY owns the Server-Function attack surface; RB-E-REACT-CORE owns the RSC primitive.
HISTORY: 2026-10-08 REOPENED: Next.js 16.4 — Cache Components recommended for every app, default in create-next-app, default in Next 17; ensureStatic; next upgrade --agent.
2026-10-01 REOPENED: Vinext reached stable 1.0 (Pages Router support, >99% compat, cache-warming, Cloudflare claims production customers) — the option row's "not production-ready" stance softened, caveats kept.
2026-10-01 ⚡TRIP FIRED (next ≥16.3.7): the scheduled September security release shipped 2026-09-30 as 16.3.8/15.5.27 (16.3.7 itself, 2026-09-29, carried no security content) — 7 of 9 announced vulnerabilities patched (1 High, 5 Medium, 1 Low; CVEs/GHSAs now in the SEPTEMBER note), 2 (1 Critical, 1 High) postponed for upstream coordination; also added the TanStack Start critical-XSS pointer (RB-E-SECURITY owns CVE-2026-102989).
2026-09-24 CORRECTED: Next.js 16.3 shipped stable 2026-08-03 (the 16.3 reading still called it a preview); Waku is at rc.1; Expo Router SSR is no longer alpha in SDK 58.
2026-07-10 CHALLENGED → WEAKENED: caveats applied (Start RSC experimental, download surge inflated by Lovable CI, no backports); the Next default and the how-much-RSC context-key SURVIVED the migration-wave attack.
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
The detailed writeup behind this entry's held Lovable fact, and the largest public Next→Start migration on record: lovable.dev (42M+ monthly uniques, ~400 routes, 910K+ lines of non-generated code) moved off Next.js/Vercel onto TanStack Start, with the mechanical code-move AI-assisted. The comparison section is the durable part, and it cuts both ways: Vite dev server at 10s start / 1.5GB RAM vs 70s / 8GB for Next 16.2+Turbopack on the same codebase (they note 16.3 claims up to 90% dev-server memory reduction); fewer server/client abstractions to hold in your head; agents make fewer framework mistakes on Start (their read: a small consistent training corpus beats a large self-contradictory one, because Next 12/14/16 answers pollute each other); BUT production bundling needed 'quite a bit of low-level configuration' where Next.js is efficient out of the box.
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 itself shipped stable 2026-08-03, the features stay opt-in.
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 full-stack alternative (its RSC is still experimental and
Start itself is a v1 release candidate). 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. Hosting no longer separates them: Next's stable Adapter API (16.2)
runs it off Vercel, and Start deploys first-party on Vercel since 2026-09-08. 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. Security fixes do not backport:
each release patches only the current Active and Maintenance LTS minors (e.g. 16.3.6/15.5.26
for the 2026-09-22 out-of-band critical), and monthly scheduled releases still get
out-of-band additions. Choosing Next means committing to track its latest minors.
TanStack Start — Vite-based, type-safe-router-first, RSC and Server Functions as explicit
APIs (RSC still experimental), Server Actions deliberately omitted. Wins when you want a less-opinionated, Vite-native
stack and tight control of the client/server seam.
React Router 8 (framework mode) / Remix — Remix merged into React Router (v7, now v8);
full-stack loaders/actions for teams already living in React Router. (Remix 3 is a separate
JSX-component pivot, distinct from this lineage; its release is set for 2026-10-02.)
Expo Router — the RN/universal meta-framework: file-based routing, SDK-56-era decoupling
from React Navigation; SDK 58 (beta) makes data loaders, SSR and middleware stable. 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