Stay on React 19.2 and turn on React Compiler 1.0 for new code — let it handle memoization; keep existing useMemo/useCallback as escape hatches (don't strip them — removing can change the compiler's output), and pin the exact compiler version if test coverage is thin.
new project → React 19.2 + Compiler from day one
web data-fetching/SSR → RSC via a meta-framework (RB-E-META-FRAMEWORKS); React Native → RSC does not apply
bundle-size-critical web → consider Preact; treat @tanstack/redact / Million / TSRX as experimental, not production bets
Options & tradeoffs
the field considered — and why each one isn’t the default here
auto-memoizes — drops most useMemo/useCallback; stable since 2025-10 (Meta prod); Rust port MERGED into SWC — ships via Rspack 2.1's built-in loader (7–13x the Babel plugin); enable via Babel/SWC/Oxc/Vite-8 plugin
React Server Components (RSC)
server-rendered components over the Flight protocol; web-only; Server Functions = the mutation path (security-sensitive — see RB-E-SECURITY)
<Activity>
hide a subtree while preserving its state (defer/restore); 100% satisfaction in State-of-React 2025; pair with Effect cleanup
<ViewTransition> / use()
animated transitions (component or native startViewTransition); use() reads promises/context under Suspense
alternative React runtimes
Preact (small, drop-in-ish); experimental @tanstack/redact (~9KB, claims 2–3x, TanStack-Start-scoped); Million; TSRX = a JSX-successor compiling to React/Preact/Solid — mostly experimental
Verified notes
React Compiler reached 1.0 STABLE (2025-10-07) and is production-ready — new code can drop most manual memoization. The Rust port LANDED: merged into SWC and shipping via Rspack 2.1's built-in SWC loader (7–13x faster than the Babel version; verified vs the Rspack 2.1 blog, 2026-07-06) — while Rolldown pulled ITS integration over napi binary size (that caveat stands, see RB-E-BUILD). React moved to the independent React Foundation (Linux Foundation, Feb 2026; exec director Seth Webster); repos moved facebook → react org (corroborated across React Status #464/#478 + TWiR). RSC/ Server Functions are a WEB concern (not RN) with an active DoS CVE history (see RB-E-SECURITY). Compiler-1.0 + RSC-DoS verified this session; other rows from release history + newsletters. Adversarially stress-tested 2026-06-25 (SURVIVES, caveats applied): 19.2 is still the stable line (19.3 in active canary — re-verify before quoting "19.2"); don't strip existing memoization when enabling the Compiler — useMemo/useCallback remain valid escape hatches.
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
The when-NOT-to caveat behind this entry's <Activity> row: hiding preserves STATE but destroys and re-creates EFFECTS on every toggle — so effect-shaped work (keyboard subscriptions, analytics, listeners) piles up subscription/setState waves each time a hidden RN screen is shown again. Pair <Activity> with disciplined effect cleanup or don't use it for effect-heavy subtrees.
Reframes rendering cost as the dominant hidden bottleneck: React's `render` doesn't just paint — it passes state down, updates context consumers, fires effects, and re-subscribes queries, so ordinary patterns (lift-state-up, effects-for-coordination, `useContext` on a whole value, deps-array callbacks) cascade renders top-down (measured ~10x CPU top-vs-leaf). The React Compiler can't save you when a prop *actually* changes. The prescribed toolkit — `useEffectEvent`/stable event callbacks (no deps-array cascades), imperative APIs over hooks (get-a-value + subscribe instead of re-render), `use-context-selector`, and providing *stable* objects through Context — extends the Erikson rendering guide below into a 'render once' discipline. Vendor angle (pitches Legend State), but the render-model reasoning is framework-agnostic. See RB-E-STATE for the state-architecture half.
The end-to-end explanation of when and why React renders — render vs commit, reconciliation, the cascade to children, memo/useMemo/useCallback, Context behavior. The mental model that makes the React Compiler's auto-memoization comprehensible rather than magic.
How React's reconciler connects to a host environment (the renderer interface), and why React Native Testing Library needed its own renderer. The canonical explanation of React's renderer architecture.
Traces the move from useEffect/React-Query/route-loaders to component-level RSC data fetching, with durable principles: component autonomy, deliberate Suspense boundaries, skeleton co-location. RSC architecture from a recognized educator.
Ten component-design patterns for SSR/hydration, multiple instances, concurrent rendering, portals, view transitions, and tainting (useId, React.cache, taintUniqueValue). A durable component-API mental model from an authoritative author.
Traces React 15's non-interruptible recursive reconciliation to Fiber's linked-list + time-slicing design — the 'why it exists' explainer for concurrent React. First in a React-internals series (key-prop, state-updates, out-of-order streaming also available).
A first-principles walk through Fiber's four phases (trigger/schedule/render/commit), the fiber-node shape, time-slicing, and the bitmask lane-priority system. Durable internals knowledge that survives version churn.
A competing-framework author argues deferred state commits and effect dependency arrays are forced by async UI, not arbitrary — even signal-based frameworks hit the same wall. An unusually credible mental model for React's most-griped-about choices.
An 18-month retrospective: how auto-memoization retired the missing-dependency bug class, the five patterns where the compiler bails out, and a staged adoption path. The mental model for the compiler era (complements the official release post in 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 React core — the compiler era, RSC, and concurrent features
Diataxis: Explanation. This page builds understanding of where React itself is in 2026
and what that means for how you write it. It is not an API reference (that's react.dev) and
not a rules-of-React linter (that's engineering-principles / ESLint). Read this for the why.
The one shift that reframes everything: stop hand-memoizing
For a decade, "React performance" meant manually wrapping things in useMemo, useCallback,
and React.memo to stop needless re-renders. The React Compiler (1.0, stable since
2025-10-07) inverts that. It analyses your components and inserts memoization for you, more
precisely than humans reliably do — across early returns and conditional branches. So the new
mental model is: write straightforward code and let the compiler memoize; manual useMemo/
useCallback become escape hatches, not defaults. (Verified against the official React
Compiler 1.0 announcement.)
That single change cascades: the old "which state library avoids re-renders" reasoning weakens
(RB-E-STATE), and "where are my missing memos" stops being a routine bug class.
The mental model: React is now stable, plural, and compiler-optimized
Three facts define core React in 2026, and they're easy to conflate:
React-the-library is mature and stable on the 19.x line (19.2 ships <Activity>,
<ViewTransition>, useEffectEvent, use()), and now lives under the independent React
Foundation (Linux Foundation, Feb 2026). Stability is the headline.
React-the-protocol (RSC). React Server Components are a server rendering model over the
Flight wire protocol. This is a web concern delivered through meta-frameworks
(RB-E-META-FRAMEWORKS); it does not apply to React Native, and its security issues are
server-side (below, RB-E-SECURITY).
React-the-projection (alternative runtimes). Preact, the experimental @tanstack/redact,
Million, and the JSX-successor TSRX are other ways to run React-shaped code. Mostly
experimental; interesting, not production defaults.
Keeping these three apart is most of "understanding modern React."
The default, and why
Stay on React 19.2 and turn on React Compiler 1.0 — let it handle memoization.
This is the low-regret baseline: you're on the stable line, you get the concurrent features,
and you delete a category of manual-memo busywork (and the bugs that come with getting it
wrong). New projects should adopt the Compiler from day one; existing apps can enable it
incrementally. On the web, reach for RSC via a meta-framework when you actually need
server rendering/data; on React Native, RSC simply doesn't apply.
The landscape, and when each piece earns its place
React Compiler 1.0 — on by default for new code; the Rust port is the in-progress part, but
the compiler itself is production-proven at Meta. Enable via the Babel/SWC/Oxc/Vite plugin
(RB-E-BUILD).
RSC + Server Functions — server-rendered components and the mutation path. Web-only,
meta-framework-delivered, security-sensitive (RB-E-SECURITY). Use when the server is part of
your architecture, not as a reflex.
Concurrent features — <Activity> (hide a subtree while preserving its state — high
satisfaction in State-of-React 2025), useEffectEvent (read latest values without re-subscribing
effects), use() (read promises/context under Suspense), <ViewTransition> (animated
transitions). Reach for them when the problem matches; they're tools, not obligations.
Alternative runtimes — Preact for bundle-size-critical web; treat @tanstack/redact,
Million, and TSRX as experiments, not production bets. The decade of React libraries is the
reason to stay on React unless a concrete driver pushes you off (RB-E-ALT-FRAMEWORKS).
Tradeoffs and failure modes to name out loud
Mutating objects you got from useState defeats the Compiler. The ecosystem's load-
bearing caveat: prefer immutable updates and plain data over behaviour-rich class instances in
render paths, or you fight the optimizer (RB-E-STATE).
Hand-memoizing by default in the compiler era. Adding useMemo/useCallback everywhere
is now noise — and occasionally counterproductive. Let the compiler work; reach for manual
memo only for measured, specific cases.
Treating RSC as universal. RSC/Server Functions are web + server. Assuming they apply to
React Native, or that their CVEs affect RN, is a category error (RB-E-SECURITY).
Chasing experimental runtimes. Betting production on redact/Million/TSRX trades a vast,
battle-tested ecosystem for unproven speed claims.
How it interacts with the rest of the stack
State (RB-E-STATE). The Compiler changes the perf calculus — choose a store for its
sharing model and ergonomics, not as a memoisation workaround.
Meta-frameworks (RB-E-META-FRAMEWORKS). RSC/Server Functions are productised there; this
entry is the primitive, that one is the frameworks.
Security (RB-E-SECURITY). The RSC/Server-Function DoS family is server-side and patched
in React 19.0.5/19.1.6/19.2.5; it does not affect React Native.
Build (RB-E-BUILD). The Compiler is a build plugin; how you enable it depends on your
bundler/toolchain.
Rendering depth. When you do need to reason about renders, the depth (render vs commit,
reconciliation, Fiber) lives in the reading and in engineering-principles, not in this page.
In one paragraph
Modern React is stable, plural, and compiler-optimized: stay on 19.2 and turn on the
React Compiler so you stop hand-writing useMemo/useCallback (just don't mutate state
objects and defeat it). Keep the three Reacts straight — the library (stable, concurrent
features), the protocol (RSC: web + server only, not RN, security-sensitive), and the projections
(Preact/redact/Million/TSRX: mostly experimental). Reach for RSC and concurrent features when the
problem calls for them, and stay on React for its ecosystem unless a concrete driver pushes you
off.
See also: RB-E-STATE (Compiler changes the state-perf calculus), RB-E-META-FRAMEWORKS
(RSC/Server Functions productised), RB-E-SECURITY (RSC CVEs are server-side), RB-E-TYPESCRIPT.
Rendering/architecture depth: the engineering-principles skill.
react-brain