React Compiler, honestly: automated memo with silent bailouts

What it automates: memoization as a compiler pass

The React Compiler is a build-time transform (a Babel plugin, slotting into Vite/Next/Metro pipelines) that rewrites components and hooks to be memoized by default. It statically analyzes each function, tracks which values depend on which inputs, and caches intermediate results — values, JSX subtrees, function identities — so that a re-render only recomputes what its changed inputs actually reach. Three honest clarifications about scope:

• It is finer-grained than your useMemo. Hand-written memoization works at the granularity you bothered to write; the compiler memoizes per expression, including JSX elements themselves, so an unchanged subtree is skipped even when the component re-runs. It routinely outperforms decent hand-memoization on breadth alone.
• It changes none of your semantics — when it applies. Compiled output must behave identically to source for rule-following code. The compiler’s entire license to rewrite is the assumption that your components are pure, props and state are not mutated, and hooks are called unconditionally — the Rules of React, now load-bearing.
• It does not make slow code fast. It removes unnecessary re-render cost. An expensive calculation that genuinely must run on changed inputs runs exactly as before; a chart that re-renders because its data really changed re-renders. Teams measuring “compiler made p95 commit time better by 30%” are measuring avoided re-renders, not faster ones.

The bailout: silent by design

When the compiler cannot prove a component follows the rules, it does not emit a half-optimization and does not fail the build — it skips the component entirely, leaving the original code untouched. Triggers it cannot verify past include: mutating props, state, or values derived from them (rows.sort(), obj.x = y on a non-local); reading or writing refs during render; dynamic property access patterns it cannot reason about; values that escape into closures with unclear lifetimes. The output difference is invisible at runtime: the component works, renders correctly, and simply re-renders as often as it did before the compiler existed.

This silence is a deliberate engineering choice — correctness over coverage; a wrong memoization corrupts UI state, a skipped one only costs CPU. But it creates the failure mode from the Hook: “compiler enabled” is not “codebase memoized.” Coverage is a property you must observe, not assume. Two observation points exist: the eslint plugin at write time, and React DevTools at runtime — compiled components are badged with a “Memo ✨” marker in the components panel, so a spot check of your heaviest screens tells you whether the optimizer actually took the deal.

The eslint plugin is the contract surface

eslint-plugin-react-compiler runs the same analysis as the compiler and reports, at write time, every place the compiler will refuse. That changes its role from style checker to coverage contract: a violation is not a nitpick, it is a named component that will silently stay unmemoized. The operational pattern for adoption:

1. Run the plugin across the codebase before enabling the compiler — the violation list is your bailout map.
2. Fix violations in the hot paths first (they are where memoization is worth money); accept cold-path violations consciously.
3. Enforce zero new violations in CI. From then on, the compileable surface only grows, and “the compiler covers this screen” is a checkable claim instead of a vibe.

Together these three steps mean coverage becomes auditable before you delete a single line of manual memo — and that order matters, because the regression in the Hook happened precisely because step three was skipped entirely.

What manual memoization still does

The compiler does not retire the manual toolkit; it narrows it to jobs the compiler structurally cannot do:

• Cross-module boundaries you do not compile. A component library published to npm ships whatever its build produced; consumers’ compilers do not reach into node_modules. If your library’s components need memoization guarantees, React.memo and stable callbacks remain part of the published contract.
• Non-component caching. Module-level caches, memoized selectors (reselect and friends), expensive pure functions called outside render — the compiler memoizes within components and hooks; it does not invent caches for your data layer.
• Bailed-out components, knowingly. Until a violation is fixed, hand memoization is the bridge — which is exactly why deleting it should follow verified coverage, not precede it.
• Semantics, not speed. A useMemo that guards a referential identity a downstream effect depends on (a deps array, a context value) encodes correctness, and the compiler preserves but does not replace your reasoning about it.

Maturity and adoption, honestly

Where it stands: years of production use at Meta scale preceded public stability, the first stable release shipped in late 2025 after a long RC, and major frameworks expose it as a config flag. What that does not mean: flip-the-switch-and-forget. The honest adoption posture is incremental — the compiler supports gradual rollout (annotation mode compiles only components marked "use memo"; directory-scoped Babel overrides confine it per package or per area), and teams that succeed run weeks of canary comparing field metrics before widening scope. Ecosystem code with rule violations is common in older dependencies and legacy corners; each is a silent bailout, not a crash, so the blast radius of enabling broadly is performance unevenness, not breakage.

And measure like an adult: record the React DevTools Profiler on your three heaviest interactions before enabling; enable; re-record. Look for fewer components rendering per commit and lower commit durations; check the Memo badge on the components you care about; watch INP in field data over a release cycle. Teams report real numbers — Meta cited meaningful wins on Quest Store-class surfaces — but your number depends on how much unnecessary re-rendering you had and how much of your tree the compiler can prove. A codebase already disciplined about memo may see single-digit percent; a codebase that never memoized may see interactions get dramatically cheaper. Faith is not a metric.