A team enables the React Compiler and deletes their useMemo and useCallback calls. Which performance problems does the compiler still not solve for them?

## Name the cost the compiler removes One cost, precisely: re-executing a component function and rebuilding its subtree when the values that component reads are unchanged. The compiler caches derived values and JSX elements, and by preserving element identity it lets React bail out of subtrees. That is the whole win. Every performance problem outside that sentence is unchanged. That is worth saying out loud in an interview, because the failure mode being probed is a team that treats the compiler as a general-purpose "make React fast" switch and stops investigating. ## Costs it does not touch **Work whose inputs really changed.** Caching helps when nothing changed. Sort a 50,000-element list keyed off a value that updates on every keystroke and the sort runs on every keystroke, compiled or not. The fix is algorithmic — index it, paginate it, debounce the input, move it off the main thread — not more memoization. **DOM volume.** Mounting and updating thousands of nodes costs layout and paint that no render cache avoids. Windowing the list remains the answer. **Everything about data.** Request waterfalls, over-fetching, missing cache, slow endpoints, oversized JSON: the compiler operates on render, and none of this is render. **Bundle size and startup.** The compiler ships a little more code than you wrote — cache slots and comparisons are code. It is a runtime-render optimisation with a marginal payload cost, so it will not improve time-to-interactive on a heavy bundle. **Effects, event handlers and layout work.** A handler that does expensive work on every keypress runs on every keypress. An effect that re-subscribes too often, a layout measurement forcing synchronous reflow, an animation fighting the main thread — all outside the compiled render path. **Genuinely frequent state updates.** If a value changes on every frame, every consumer of it re-renders on every frame; nothing was wasted, so nothing can be pruned. Restructuring — moving that state down to the smallest component that needs it, or deferring the expensive consumer — is the actual fix. **Uncompiled code at the seams.** A third-party component the compiler did not process, or one it bailed out on, does not gain stable identity from your side of the boundary. ## Memoization you should not delete A subtler point. Not every `useMemo` in a codebase was ever about render cost. Some exist for *identity semantics*: a value used as a `WeakMap` key, an object handed to a non-React library that caches by reference, or a mutable container something else holds onto. Those calls encode a requirement, not an optimisation, and deleting them because "the compiler handles memoization now" can change behaviour. `useRef` is usually the clearer expression of that intent — but re-read the call site before you sweep it away. ## What replaces the deleted work The habit worth keeping is the one that existed before memo hooks: composition. Moving state down, passing an expensive subtree as `children` so it keeps identity, splitting a component so a fast-changing value re-renders less of the tree — these reduce the *amount* of rendering rather than caching its result, and they still pay off in a compiled app. The compiler is a floor under sloppy identity handling, not a substitute for structure. ## How to answer well Start by naming the single cost it removes, then enumerate categories rather than examples: work that genuinely changed, DOM volume, data, bundle, non-render work, and the seams. Close on process — you profile a real interaction before and after, because a well-composed app may show almost no gain, and "we enabled the compiler" is not a performance result until something measured got faster.