title: "React Compiler: perché nel 2026 useMemo e useCallback non servono quasi più" tags: [react, performance, react-compiler]

React Compiler: perché nel 2026 useMemo e useCallback non servono quasi più

Dal rilascio della versione 1.0, il React Compiler si è diffuso al punto che nel 2026 scrivere a mano useMemo, useCallback e React.memo è diventato l'eccezione, non la regola. La memoizzazione la fa il compilatore, in fase di build.

Cosa fa il React Compiler

Il React Compiler è uno strumento di build-time: analizza i componenti e gli hook prima che il codice arrivi al browser e inserisce in automatico la memoizzazione dove serve, in modo sicuro. In pratica si prende in carico quel lavoro di ottimizzazione manuale che per anni abbiamo fatto con useMemo e useCallback.

Il supporto è già integrato nei framework che conta: Next.js e Vite.

Cosa cambia nel modo di scrivere componenti

La differenza più evidente è il rumore visivo che sparisce. Un componente prima si riempiva di wrapper difensivi:

// Prima
const totale = useMemo(() => calcola(items), [items]);
const onSelect = useCallback((id) => setSel(id), []);

// Con il compilatore
const totale = calcola(items);
const onSelect = (id) => setSel(id);

Lo stesso comportamento, senza le dipendenze da tenere allineate a mano — che poi erano una delle fonti di bug più subdole in React.

useMemo e useCallback sono morti?

No, ma sono diventati strumenti di nicchia. Restano utili in due casi:

• quando integri librerie di terze parti che si basano sull'uguaglianza per riferimento;
• quando hai misurato un problema di performance che le euristiche del compilatore non coprono.

La regola pratica del 2026 si è ribaltata: non memoizzi per default e ottimizzi a mano solo dove i numeri lo chiedono. Codice più pulito, meno dipendenze sbagliate, e in molti casi qualche punto di performance in più — senza scriverlo tu.

Il mio approccio

Sul lavoro questa è la direzione che seguo: lasciare che il compilatore gestisca la memoizzazione e intervenire a mano solo quando un profiling lo giustifica. È coerente con un principio che mi porto dietro su tutto lo stack — non ottimizzare a intuito, ottimizzare su misura. Meno codice difensivo significa meno superficie per gli errori, e componenti che si leggono per quello che fanno.