DEV Community

Cover image for I Threw React Compiler 1.0 at a Real Codebase
蔡俊鹏
蔡俊鹏

Posted on

I Threw React Compiler 1.0 at a Real Codebase

#vue #react

So React Compiler 1.0 landed in production last October. If you're like me, you skimmed the announcement, nodded, and went back to your useMemo-infested codebase.

Then months passed. Next.js 16 shipped with it enabled by default. Expo SDK 54 turned it on in new projects. Vite 8 rewired its plugin system around it. And somewhere in between, I realized I'd been sitting on a tool that could change how I write React without ever actually testing it at scale.

So I did what any reasonable developer would do: I took a mid-sized production app, flipped the switch, and waited to see what breaks.

Here's what I found — the good, the awkward, and the one thing that caught me completely off guard.

The "Just Enable It" Experience

The official pitch is simple: install the Babel plugin, add a config line, and the compiler starts auto-memoizing your components at build time. You write plain code. It figures out what to cache.

// You write this:
function Dashboard({ user, transactions }) {
  const displayName = `${user.firstName} ${user.lastName}`;
  const recentTx = transactions.filter(tx => tx.date > Date.now() - 86400000);
  const total = recentTx.reduce((sum, tx) => sum + tx.amount, 0);

  return (
    <div>
      <h1>{displayName}</h1>
      <p>Today: ${total.toFixed(2)}</p>
      <TransactionList items={recentTx} />
    </div>
  );
}

// Compiler sees the dependency graph and decides what to cache -- you don't touch the code.
Enter fullscreen mode Exit fullscreen mode

I enabled it on a Next.js 15 project, roughly 40 pages with moderate interactivity. First build was maybe 10% slower, noticeable but not painful. The app rendered fine. No errors. I thought "well that was anticlimactic."

Then I checked the re-render counts.

A list view that previously triggered 8 redundant re-renders on a single state change dropped to 2. A filtering component with nested dropdowns went from "who designed this" to actually smooth.

The boring truth: it just works for most components. No fireworks, no migration drama, just less work for the browser.

Where the Compiler Shines (and Where It Doesn't)

The easy wins

Any component that derives data from props or state (filter a list, concatenate strings, compute totals) gets cached automatically. These are exactly the cases where most developers either forget to memoize or add useMemo incorrectly anyway.

Over on the React subreddit, someone posted that the compiler "completely transformed" their app. Navigation felt snappier, form interactions stopped lagging, animations smoothed out. Zero optimization work on their part.

The "meh" zone

For components that already had good memo coverage, the compiler doesn't add much. If your senior dev already laced the codebase with useMemo and useCallback everywhere, the speedup is marginal. A few re-renders saved here and there.

The real value is for teams with mixed skill levels. One junior dev's un-memoized list component causing a cascade? Solved. One messy dependency array running an expensive calculation on every render? Handled.

The gotcha I didn't expect

Here's the thing that bit me: if you blindly nuke all manual memoization on old projects, you'll break things.

I tried it on one page. Stripped out useMemo, useCallback, React.memo. The page still worked, but I introduced two infinite re-render loops. The compiler's logic conflicted with custom hooks that mutated state in ways it couldn't analyze.

The safe path:

  1. Enable the compiler first
  2. Let it run alongside your existing memoization
  3. Clean up hooks one component at a time after verifying the compiler handles it

Also: effect dependencies are still on you. The compiler won't touch useEffect. If your effect fires on every render because of a missing dependency, that's still your problem.

Framework Support: What I Found Across Three Setups

Next.js 16

Built-in support is stable. Next.js uses a custom SWC optimization that only applies the compiler to files with JSX or hooks, keeping build times reasonable:

// next.config.js -- Next.js 16 enables it by default for new projects
const nextConfig = {
  reactCompiler: true,
};
Enter fullscreen mode Exit fullscreen mode

For older projects, install babel-plugin-react-compiler and add the flag. The official docs cover the rest.

Vite 8

This one tripped me up. @vitejs/plugin-react v6 replaced the built-in Babel with oxc (Rust-based transpiler), so the old react({ babel: { plugins: [...] } }) syntax doesn't work anymore. Here's what works:

npm install -D @rolldown/plugin-babel babel-plugin-react-compiler
Enter fullscreen mode Exit fullscreen mode 
import react, { reactCompilerPreset } from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';

export default {
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset()] }),
  ],
};
Enter fullscreen mode Exit fullscreen mode

Took me about 10 minutes to figure out. Vite's migration guide explains the oxc transition if you're upgrading from v7.

Expo SDK 54

React Native devs get the most out of this one. SDK 54 enables the React Compiler in the default template. RN has always had worse memo coverage than web -- most projects have embarrassingly few React.memo wrappers. Getting this for free changes the mobile performance game.

The "Use No Memo" Escape Hatch

When the compiler can't handle a file (usually because it mutates state in ways that violate the Rules of React), you can opt out:

"use no memo";

// This file won't be processed by the React Compiler
function ComplexWidget({ data }) {
  // ... your existing code
}
Enter fullscreen mode Exit fullscreen mode

There's also "use memo" to explicitly opt in if the compiler's heuristic skips a file.

I used "use no memo" exactly once, on a legacy analytics wrapper that manually tracked render counts via mutation. Everything else the compiler handled without complaint.

One tip: get eslint-plugin-react-hooks to zero warnings before enabling the compiler. The rule set is now wired into the compiler's analysis. If ESLint flags it, the compiler probably can't optimize it.

The Verdict After a Month

Yes, you can finally delete some of those useMemo calls. But not all of them, not all at once, and not without checking.

What the React Compiler does well:

  • Catches the memoization that should exist but doesn't
  • Eliminates boilerplate on new components
  • Makes React apps faster with zero effort from average developers

What it doesn't do:

  • Fix bad architectural decisions (too much state in one tree, no data normalization)
  • Manage effect side effects
  • Replace understanding why React re-renders

One line summary: we've moved from "optimize by convention" to "optimize by compiler." But the compiler is a safety net, not a silver bullet. Write clean code, use the compiler, and clean up old hooks gradually.

Good React code was never about "it looks maximally memoized." It's about "it doesn't lag, and you can actually read it."

The original post with more detailed benchmarks is on my blog

A few more articles from the same series you might find useful:

Top comments (0)