entries app-architecture · verified 2026-07-10 · react + react-native

Meta-frameworks (full-stack React)

reviewedconfidence: mediumtrack: weakenedthis tier holds 50% on the public scorecard (3/19 graded · 0 overturned) →

related decisions: nav

re-verified 3× — 2026-07-13 · 2026-07-10 · 2026-07-06 · changelog

recommendation

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	44.7M/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	18.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; 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

evidence: npm weekly downloads (signals snapshot) · “ships in n/D” = adoption across the production-app census, honest denominators

npm weekly downloads (from the corpus's last signals run): next 44.7M · @tanstack/react-start 18.4M · astro 3.9M · waku 22k

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. Stress-tested 2026-07-10 (WEAKENED → caveats applied; the Next-default and the how-much-RSC context-key both SURVIVED the migration-wave attack).

Canonical reading

Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.

Who Owns the Tree? RSC as a Protocol, Not an ArchitectureTanStack

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.

React Server Components in TanStackAdam Rackis (Frontend Masters)

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.

Moving Railway's frontend off Next.jsVictor Ramirez (Railway)

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.

use client in Next.jsPunit Sethi

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.

Next.js 16.3: Instant Navigations (16.3 Preview)Andrew Clark & Josh Story (Next.js team)

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).

Different Hydration and Rendering StrategiesNeci Dan (neciudan.dev)

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.

Sources

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.

See also: RB-E-NAV (client routing), RB-E-REACT-CORE (RSC/Server Functions/use()), RB-E-DATA (where the data layer lives), RB-E-CROSSPLATFORM (Expo Router), RB-E-SECURITY (Server-Function surface). Architecture depth: the engineering-principles skill.

Related in app-architecture: state · data · p2p · nav · forms · networking · crossplatform · desktop