React Compiler: The Death of Manual Memoization?

Ever wondered why we spend so much of our lives wrapping functions in useCallback and components in React.memo just to keep a design system from crawling to a halt? It's often felt like a tax we pay for choosing React—a constant mental overhead of tracking referential identity.

The React Compiler is here to change that. I've been digging into how this build-time tool shifts the landscape for design system engineers. It's not just a performance boost; it's a fundamental shift in how we design our component APIs.

What's actually happening under the hood?

At its core, the React Compiler is a Babel plugin that automates what we've been doing manually for years. According to the official docs, it "automatically optimizes your React app" by understanding the Rules of React at build time. It effectively treats your code as if every component and hook dependency were already wrapped in memoization primitives.

The result? Normal React code that behaves as if it's perfectly optimized. In early production tests at Meta and across the community, it's shown minimal impact on initial load but significant improvements in interaction snappiness. For a design system, this is massive.

Cleaning up the API surface

In the past, I'd often see (and write) Button components that looked like a science experiment of performance hooks. We did it to protect the consumer from unnecessary re-renders, but it made the code brittle and hard to read.

// The 'Old' way: Defensive memoization
export const Button = React.memo(({ kind, onClick, children }) => {
  const className = useMemo(() => computeButtonClass(kind), [kind]);
  const handleClick = useCallback((e) => {
    trackClick(kind);
    onClick?.(e);
  }, [kind, onClick]);

  return (
    <button className={className} onClick={handleClick}>
      {children}
    </button>
  );
});

With the compiler, we can ditch the boilerplate. If the component is pure and prop-driven, the compiler handles the heavy lifting. We can go back to writing clean, declarative JavaScript.

// The 'New' way: Clean and readable
export function Button({ kind, onClick, children }) {
  const className = computeButtonClass(kind);
  const handleClick = (e) => {
    trackClick(kind);
    onClick?.(e);
  };

  return (
    <button className={className} onClick={handleClick}>
      {children}
    </button>
  );
}

Where the Compiler still needs a hand

It's tempting to think we can just switch it on and forget about performance forever. But as the folks at PerfPlanet noted, the compiler "can't catch all re-renders—and it never will." There are specific scenarios where design system authors still need to be intentional:

Non-React Boundaries: If your component interacts with DOM events, imperative APIs, or external state stores, the compiler can't always reason about those side effects.
Identity-Sensitive Consumers: If a consumer uses one of your props (like an onChange) as a key in a Map or an effect dependency, you might still want to ensure stability manually if the compiler's inference isn't enough.
Impure Work: Things like timers, subscriptions, or direct DOM measurements are still outside the compiler's primary scope.

Rethinking Component Boundaries

One of my favourite side effects of the compiler is that we need fewer "micro-components." We used to split components purely to create a memoization boundary. Now, we can group related UI more naturally without worrying as much about render cascades.

However, boundaries still matter for the Server/Client split in React 19. Your design system architecture should still clearly define where the client interactivity begins, especially when dealing with complex stateful components like Data Grids or Command Palettes.

Adopting the Compiler safely

The React team has made the compiler incrementally adoptable. For library authors, I'd recommend starting by running the healthcheck: npx react-compiler-healthcheck@latest. This will tell you if your code follows the Rules of React strictly enough for the compiler to do its job.

• • •

Wrapping Up

The React Compiler makes manual memoization like useMemo and useCallback optional for most pure components.
Design system APIs can become much simpler and more declarative without sacrificing performance.
You still need to be mindful of component boundaries, especially when interfacing with non-React code or external state.

I'd encourage you to try enabling the compiler on a single directory of your design system and profiling the results. It's a glimpse into a future where we spend less time fighting the framework and more time building great user experiences.

If you want to go deeper and learn how to build real, production-ready CSS design systems step by step, check out my full course here: CSS Design Systems Course

If you want this whole token handoff to stop being a manual job, Design System Sync is the Figma plugin I built to handle it end to end.

Let's chat more about React 19 and design systems over on Twitter or LinkedIn. I'd love to hear your thoughts on the compiler!

Post not found