You can delete your useMemo: what the React Compiler does

The React Compiler moves memoization from something you do by hand to something the build does for you - which means most of the useMemo, useCallback, and React.memo you've been sprinkling around can simply go away. In React 19 the compiler is generally available, and the practical effect is real: components you write as plain, readable functions get automatically optimized, with reports of 20-60% fewer unnecessary re-renders and zero code changes. This isn't a new API to learn; it's an old chore you get to stop doing. The one thing worth understanding is the mechanism - because knowing how it decides what to memoize tells you the handful of cases where you still reach for a manual hook.

Why this matters now

For years, React performance work meant manually wrapping values in useMemo, functions in useCallback, and components in React.memo - and getting the dependency arrays exactly right, or quietly introducing stale-value bugs. It was fiddly, easy to over-apply, and easy to forget precisely where it mattered. The React Compiler's whole premise is that a machine does this analysis better and more consistently than a human sprinkling hooks by feel.

The payoff shows up in the numbers. Independent write-ups of the compiler in production report roughly 20-60% fewer re-renders with no source changes, simply by enabling it (Makers' Den). And the ecosystem has moved: React is used by roughly 47% of professional developers (Stack Overflow 2025), and TypeScript became the most-used language on GitHub by contributor count in 2025 - so a compiler that optimizes the default React-plus-TypeScript stack touches a very large amount of the web.

The mechanism: purity analysis at build time

Here's what actually happens, and it's the part worth internalizing. The React Compiler is a build step - a Babel plugin (or a faster SWC one) that transforms your components during compilation, before any code reaches the browser.

At build time the compiler runs a purity analysis on each component: it checks that the function is pure (no side effects during render), that you're not mutating props, and that you're not reading non-deterministic values mid-render. When a component passes, the compiler injects equality checks around individual props and values, and skips re-rendering the subtrees whose inputs haven't changed (Makers' Den).

The important detail is the granularity. Rather than the blunt instrument of wrapping a whole component in React.memo, the compiler memoizes at the level of individual props and values - closer to optimal than most hand-tuning, and applied everywhere it's safe rather than only where someone remembered to.

The compiler doesn't make React faster by magic. It does, automatically and everywhere, the exact memoization work good engineers used to do by hand in a few places - and it never forgets a dependency.

When you still keep a manual hook

"Delete your useMemo" is the headline, not the whole truth. useMemo and useCallback are still in React 19, and there's a clear rule for when they earn their place:

• Let the compiler handle it for ordinary component logic - derived values, callbacks passed to children, expensive calculations from props or state. This is the overwhelming majority of cases.
• Keep a manual hook when the compiler can't prove a value is safe to memoize: non-obvious purity, values entangled with third-party libraries the compiler can't see into, or an interop boundary where you need explicit control. When the compiler can't be sure, it conservatively leaves the code alone - so a deliberate hook is how you cover that gap.

The mental shift: manual memoization goes from your first move to your last one. You write plain components, let the compiler optimize, and reach for a hook only when profiling shows the compiler left something on the table.

Our opinion

Our take: enable the compiler, then delete memoization aggressively - but keep profiling honest. The biggest win here isn't the raw re-render percentage; it's readability. Components stop being cluttered with performance plumbing and start reading like the logic they actually express, which is worth as much for maintenance as the speed is for users. Code you can confidently delete is a feature, and the compiler makes a lot of memoization deletable.

We'd add one caution: automatic doesn't mean invisible. The compiler only optimizes code it can prove is pure, so the discipline that pays off now is writing genuinely pure components - no sneaky mutation, no reading random values mid-render - because that's what lets the compiler do its job across your whole tree. This fits how we think about the modern React stack generally: the framework increasingly handles the mechanical work, and your job is to give it clean inputs, the same way Server Components moved rendering work to where it belongs.

How Ashvara helps

We build fast React and Next.js web apps, and adopting the compiler well is exactly the kind of quiet, high-leverage work we do: turning it on, verifying with real profiling rather than vibes, stripping out the manual memoization it makes redundant, and fixing the impurities that stop it from optimizing. The result is a codebase that's both faster for users and cleaner for whoever maintains it next.

If you've got a React app that feels sluggish, or you want it built right on the modern stack from the start, that's our web development work. Talk to us and we'll make it fast without making it fragile.

Source: Makers' Den - React Compiler: what you need to know about automatic memoization (build-time purity analysis, per-prop memoization, 20-60% fewer re-renders); React 19 ships the compiler to general availability.