The React Compiler vs Signals: Why React Refused the Fine-Grained Reactivity Train

Between 2021 and 2024, an architectural schism quietly divided frontend systems engineering.

Ryan Carniato demonstrated with SolidJS that fine-grained reactivity could deliver near-vanilla JavaScript performance by discarding the Virtual DOM entirely ^[3]. Rich Harris and the Svelte core team followed suit in Svelte 5, deprecating their compiler-driven syntax in favor of explicit reactive primitives called Runes ($state()) ^[4]. Evan You solidified Vue’s reactivity model ^[5], while Misko Hevery architected Qwik around signal-based resumability ^[8].

Across the entire web landscape, consensus appeared absolute: the top-down re-render model was an architectural dead end. To make web applications fast, state changes should surgically mutate the exact DOM text node that depends on them, bypassing component tree reconciliation altogether.

Yet, inside Meta, the React core team looked at the same benchmarks ^[6] and made a radically defiant choice. They chose not to adopt signals.

Instead, they spent four years building an optimizing compiler—first codenamed React Forget, now released as the React Compiler (babel-plugin-react-compiler) ^[1]. Rather than asking developers to wrap values in reactive signal primitives, the compiler analyzes raw, mutable JavaScript using High-Level Intermediate Representation (HIR) and automatically injects fine-grained memoization scopes at build time.

Why did React refuse the signals train? Why bet the future of the world's most dominant UI library on compiler static analysis? And what are the physical runtime trade-offs between compile-time dependency analysis and runtime reactive subscriber graphs?

To trace how state mutations propagate through these two disparate runtimes, examine the data-flow topology illustrated in Figure 1 below.

Figure 1: Comparative data-flow topologies of Top-Down Compiler Memoization versus Fine-Grained Reactive Subscriber Graphs. In the compiler model, execution remains top-down but is arrested by memoization slots; in the signal model, component scopes execute only once, and signals notify DOM bindings directly. Source: Adapted from Savona & Hanlon (2024) ^[1] and Carniato (2021) ^[3].

As Figure 1 reveals, this divergence is not a trivial syntactic disagreement over accessor functions (count() vs count). It is a fundamental philosophical split between ambient dependency graphs managed in client RAM and top-down deterministic functional execution bounded by static analysis.

1. The Sisyphus of the Virtual DOM: The Hidden Cost of Top-Down Reconciliation

To understand why the React Compiler was conceived, one must revisit the original contract of React: UI as a pure projection of state, formulated by Jordan Walke as $UI = f(state)$.

In Walke's original mental model, whenever application state changed, the component function simply executed again from top to bottom. It allocated new local objects, instantiated new inline closures, and returned a fresh tree of Virtual DOM descriptors. React’s reconciliation engine (Fiber) traversed the tree, compared the new descriptors against the previous render, and dispatched the minimal delta of mutations to the browser's Document Object Model.

This mental model was extraordinarily liberating. Developers no longer wrote manual event listeners or fragile DOM mutations. But as applications scaled from toy todo lists to enterprise dashboards containing tens of thousands of component nodes, Walke’s pure functional model hit an unforgiving physical reality: the cascading re-render penalty.

By default, when a parent component in React re-renders, every single child component in its subtree re-renders as well. If an input field in a root layout updates on every keystroke, thousands of child components down the tree re-execute their JavaScript functions, re-allocate closures, and force Fiber reconciliation passes—even if ninety-nine percent of them display static data that never changed.

To stop this cascading re-render cascade, React introduced manual memoization hooks in version 16.8:

• useMemo: Caches expensive computation results across render passes.
• useCallback: Preserves closure reference equality between renders.
• React.memo: Bypasses child component reconciliation if props are shallowly identical.

The Breakdown of the Manual Memoization Contract

In practice, manual memoization proved to be a psychological and operational failure across engineering teams worldwide:

1. The Broken Dependency Array: A developer forgets a single variable in a dependency array, and a closure captures stale state. The compiler cannot catch it without aggressive ESLint rules, and ESLint frequently suggests fixes that cause infinite render loops.
2. Viral Contagion: Memoization is strictly all-or-nothing. If ComponentA memoizes its props, but its parent passes an un-memoized inline callback (onClick={() => doSomething()}), the reference changes on every frame, and ComponentA's React.memo check is rendered 100% useless.
3. The Cognitive Tax: Engineering organizations spent up to thirty percent of their sprint cycles profiling DevTools flamegraphs, arguing in pull requests over whether a five-line array mapping warranted useMemo, and debugging subtle memory leaks caused by lingering closure dependencies.

The React Compiler was commissioned to solve this systemic breakdown: restoring the original simplicity of $UI = f(state)$ by making memoization an invisible property of the build toolchain rather than an endless manual chore.

2. The 200-Millisecond Reckoning: Google INP and the SSA Compiler Breakthrough

If manual memoization was an acknowledged pain point as early as 2019, why did the React Compiler take until 2024 to materialize?

The timeline was dictated by two converging forces: a major theoretical breakthrough in JavaScript compiler construction, and an existential ultimatum delivered by the Google Chrome team.

The Static Single Assignment (SSA) Breakthrough

JavaScript is notoriously hostile to static compilation. Unlike Rust or Swift, JavaScript is dynamic, loosely typed, and heavily reliant on reference mutation. An object passed into a function can be mutated by reference inside a callback, properties can be deleted, and global prototypes can be monkey-patched.

Building a compiler that could automatically insert memoization without changing the semantic behavior of existing code required porting advanced compiler architecture—specifically Static Single Assignment (SSA) form pioneered by Cytron, Ferrante, Rosen, Wegman, and Zadeck ^[2]—into the Babel AST pipeline.

As illustrated in Figure 2 below, the compiler lowers raw Babel AST into an intermediate representation where every variable is assigned exactly once, allowing rigorous data-flow and lifetime analysis.

Figure 2: The five-stage compilation pipeline of the React Compiler. Source: Architecture of babel-plugin-react-compiler, adapted from Savona et al. ^[1].

In the pipeline depicted in Figure 2, the compiler translates JavaScript into a High-Level Intermediate Representation (HIR). In this form, it constructs a formal Control Flow Graph (CFG) that tracks every variable from its declaration to its destruction.

By calculating the precise "liveness" of every value, the compiler can mathematically prove whether an object might be mutated downstream. If a value is guaranteed immutable across a render pass, the compiler groups it into a Reactive Scope—an automated memoization block that caches both the computation and the resulting JSX elements.

The Google INP Ultimatum

While Meta worked on the compiler theory, the Google Chrome team delivered an external catalyst. In March 2024, Google officially deprecated First Input Delay (FID) and elevated Interaction to Next Paint (INP) to a Core Web Vital ranking signal ^[7].

FID was an easy metric to game: it measured only the time until the main thread began processing an event handler. INP, by contrast, measures the entire elapsed duration from the moment a user touches a screen or clicks a key until the browser physically paints the updated frame to the display.

Under INP, re-rendering deep Virtual DOM trees on mid-range Android devices running budget ARM processors causes frame drops exceeding the 200-millisecond threshold. React applications faced immediate SEO penalties and conversion drops unless their re-render overhead was eliminated. The React Compiler transformed from an internal Meta optimization project into a necessary survival mechanism for the React ecosystem.

3. The Heresy of Signals: Why React Rejected Fine-Grained Reactivity

While React spent years solving the SSA compilation problem, the rest of the frontend world took a completely different path: Signals.

Pioneered by Knockout.js in 2010, perfected by Ryan Carniato in SolidJS ^[3], and adopted by Preact, Vue ^[5], Svelte 5 ^[4], and Angular, signals abandon the concept of component-level re-rendering entirely.

A signal is an object that wraps a value and maintains a list of subscribers. When a signal's value changes, it does not re-run the component function. It notifies only the specific DOM text node or attribute bound to that signal.

The Architectural Case for Signals

Framework authors champion signals because they eliminate the Virtual DOM entirely:

• Zero Component Re-Execution: The component function acts as a setup script; it runs exactly once during mounting.
• Minimal Memory Overhead: No Fiber trees or Virtual DOM nodes are allocated in JavaScript heap memory.
• Near-Vanilla JavaScript Speed: State updates translate directly into native DOM mutations (node.data = newValue), outperforming React in raw synthetic benchmarks ^[6].

Why Meta Refused Signals

If signals are demonstrably faster in raw micro-benchmarks ^[6], why did the React team categorically reject them?

In interviews and design notes, React core team members Sebastian Markbåge and Joe Savona articulated three fundamental reasons ^[1]:

1. Preserving Idiomatic JavaScript ($UI = f(state)$)

Signals introduce specialized container types. You do not deal with plain numbers or strings; you deal with signal accessors:

// SolidJS: Accessor function call required
const [count, setCount] = createSignal(0);
console.log(count()); // Must invoke as a function!

// Svelte 5: Runes syntax
let count = $state(0);

In signals-based frameworks, destructuring props breaks reactivity. If you write const { name } = props, you decouple the property from its underlying reactive getter. React was unwilling to abandon idiomatic JavaScript destructuring, which is ubiquitous across millions of npm packages.

2. Ecosystem Gravity and Backward Compatibility

React is the operating system of web development. Over one-third of all websites on the internet rely on React or its ecosystem.

Transitioning React to signals would have triggered an catastrophic ecosystem rupture comparable to the Python 2 to Python 3 transition or Angular 1 to Angular 2. Every UI component library (Material UI, Radix, Shadcn), state manager (Zustand, Redux), and form library would have had to be discarded or rewritten.

3. Concurrent Rendering and Interruptible Priorities

React’s architecture is built around Concurrent Mode: the ability to interrupt a low-priority render pass (such as pre-rendering an offscreen search list) if a high-priority user event (such as typing into an input field) occurs.

Signals operate as a synchronous push notification graph. Once a signal fires, its dependency network propagates immediately. Coordinating time-slicing, speculative rendering, and state rollbacks across an ambient reactive graph is notoriously difficult compared to pure functional state trees.

4. Under the Hood: Dissecting the Compiler's Generated Bytecode

To see the React Compiler's mechanics in action, examine how it transforms standard, un-memoized TypeScript into indexed cache slots.

The Input Code (What You Write):

// components/cart-summary.tsx
export default function CartSummary({ 
  items, 
  taxRate, 
  onCheckout 
}: { 
  items: Array<{ id: string; price: number; name: string }>; 
  taxRate: number; 
  onCheckout: (total: number) => void; 
}) {
  const subtotal = items.reduce((acc, item) => acc + item.price, 0);
  const tax = subtotal * taxRate;
  const total = subtotal + tax;

  return (
    <div className="cart-summary">
      <h2>Order Summary</h2>
      <p>Subtotal: ${subtotal.toFixed(2)}</p>
      <p>Tax: ${tax.toFixed(2)}</p>
      <h3>Total: ${total.toFixed(2)}</h3>
      <button onClick={() => onCheckout(total)}>Proceed to Checkout</button>
    </div>
  );
}

The Output Code (What the Compiler Emits):

When compiled with babel-plugin-react-compiler, the function is transformed into an array-indexed memoization cache managed by React’s internal useMemoCache hook:

function CartSummary(t0) {
  const $ = useMemoCache(9); // Allocates 9 persistent cache slots
  const { items, taxRate, onCheckout } = t0;

  // Scope 1: Calculate subtotal, tax, and total
  let subtotal;
  let tax;
  let total;
  if ($[0] !== items || $[1] !== taxRate) {
    subtotal = items.reduce((acc, item) => acc + item.price, 0);
    tax = subtotal * taxRate;
    total = subtotal + tax;
    $[0] = items;
    $[1] = taxRate;
    $[2] = subtotal;
    $[3] = tax;
    $[4] = total;
  } else {
    subtotal = $[2];
    tax = $[3];
    total = $[4];
  }

  // Scope 2: Memoize onClick callback
  let t1;
  if ($[5] !== onCheckout || $[4] !== total) {
    t1 = () => onCheckout(total);
    $[5] = onCheckout;
    $[6] = total;
    $[7] = t1;
  } else {
    t1 = $[7];
  }

  // Scope 3: Memoize JSX tree
  let t2;
  if ($[2] !== subtotal || $[3] !== tax || $[4] !== total || $[7] !== t1) {
    t2 = (
      <div className="cart-summary">
        <h2>Order Summary</h2>
        <p>Subtotal: ${subtotal.toFixed(2)}</p>
        <p>Tax: ${tax.toFixed(2)}</p>
        <h3>Total: ${total.toFixed(2)}</h3>
        <button onClick={t1}>Proceed to Checkout</button>
      </div>
    );
    $[8] = t2;
  } else {
    t2 = $[8];
  }

  return t2;
}

Systems Engineering Analysis of the Output:

1. Zero Runtime Hook Overhead: Notice that the compiler did not emit useMemo or useCallback. Traditional hooks allocate internal Fiber linked-list nodes and dependency arrays. The compiler’s useMemoCache is a flat, dense array, indexed by integer constants ($[0], $[1]), minimizing memory allocation and garbage collector pressure.
2. Hierarchical Scope Separation: If taxRate changes but items remains identical, the compiler skips the expensive array reduction and updates only the tax calculation.
3. JSX Descriptor Preservation: If none of the inputs mutated, the compiler returns the identical object pointer ($[8]). When React reconciles this component, it performs an $O(1)$ reference equality check (prevElement === nextElement) and completely bypasses Fiber reconciliation for the entire subtree.

5. Comparative Architecture: React Compiler vs The Modern Field

To evaluate the trade-offs across modern frontend engineering, Table 1 compares the reactivity architectures of leading frameworks across five technical dimensions.

Table 1: Architectural comparison of reactivity mechanisms across modern web UI runtimes. Synthesized from primary framework specifications ^{[1] [3] [4] [5] [8]}.

6. Architectural Conclusion: The Compiler as an Invariant Shield

The choice between the React Compiler and fine-grained signals is not merely an engineering benchmark dispute; it is a battle over the locus of complexity in software systems.

Signals place complexity into the runtime and the developer’s mental model: developers must understand reactivity graphs, avoid destructuring props, and manage signal lifecycles.

The React Compiler shifts complexity entirely into the build toolchain: developers write plain, natural JavaScript, while a multi-pass SSA compiler shoulders the burden of mathematical optimization.

By betting on the compiler, React reaffirmed its core philosophical thesis: human beings should write declarative, idiomatically simple code, and machines should do the tedious work of making it performant.

References & Further Reading

1. Savona, J., & Hanlon, R. (2024). Forget About Memo: The React Compiler. React Conf 2024. https://react.dev/blog/2024/05/15/react-compiler-preview ↩︎
2. Cytron, R., Ferrante, J., Rosen, B. K., Wegman, M. N., & Zadeck, F. K. (1991). Efficiently Computing Static Single Assignment Form and the Control Dependence Graph. ACM Transactions on Programming Languages and Systems (TOPLAS), 13(4), 451–490. https://doi.org/10.1145/115372.115320 ↩︎
3. Carniato, R. (2021). SolidJS: Reactive Javascript The Way It Should Be. JS World Conference. https://www.solidjs.com/ ↩︎
4. Harris, R. (2023). Svelte 5: Runes Architecture and Design RFC. Svelte Blog & RFC Repository. https://svelte.dev/blog/runes ↩︎
5. You, E. (2022). Degrees of Reactivity: From Svelte to Vue to Solid. Vue.js Architectural Design Notes. https://blog.vuejs.org/ ↩︎
6. Kraus, S. (2024). JS Framework Benchmark: Comprehensive Performance Comparison. GitHub Repository. https://github.com/krausest/js-framework-benchmark ↩︎
7. Google Chrome Team (2024). Advancing Interaction to Next Paint (INP) to a Core Web Vital. W3C Web Performance Working Group & web.dev. https://web.dev/articles/inp ↩︎
8. Hevery, M. (2022). Qwik: A New Kind of Web Framework Built for Resumability. Builder.io Architecture Notes. https://qwik.dev/docs/concepts/resumable/ ↩︎