Il Tuo Codice React Fa Schifo (e la Colpa è Tua). Confessioni di un Senior Dev.

Quando il progresso ti sorpassa e tu resti a guardare il muro.

Lunedì mattina. Il caffè è una brodaglia, la deadline è un cappio al collo e l'applicazione, quella che doveva 'spaccare tutto', si muove come un bradipo con la sciatica. Il team a Kampala è in piedi da 18 ore a caccia di un bug che, in realtà, non è un bug. È un sintomo. Un sintomo di qualcosa di più marcio, annidato nelle fondamenta del frontend: il debito tecnico che hai accumulato scegliendo di ignorare l'inevitabile.

Parliamoci chiaro. Nel 2026, continuare a scrivere codice come se fossimo nel 2018 non è una scelta stilistica. È autolesionismo aziendale. Qui in ThinkPink, tra i fumi industriali di Rosignano e la polvere rossa di Kampala, ne vediamo a decine di aziende così. Intrappolate in architetture che le stanno dissanguando lentamente, un re-render inutile alla volta. È ora di smetterla con le favole e guardare in faccia la bestia.

I React Hooks non sono una moda. Sono il minimo sindacale.

Ve le ricordate le class components? Certo che sì. Quell'inferno di codice verboso, il this che faceva i capricci come un bambino viziato, la logica di una singola feature spalmata su tre metodi diversi del ciclo di vita. Per anni ci siamo detti che 'si fa così'. Era una bugia. Era solo il modo meno peggio che avevamo. Mantenerle, scalarle, debuggarle... un bagno di sangue.

Poi, quasi in sordina, sono arrivati gli Hooks. E non hanno rivoluzionato nulla. Hanno solo fatto quello che andava fatto fin dall'inizio: rendere lo sviluppo React logico. Gli Hooks ti permettono di usare stato e ciclo di vita dentro stupidi, semplici, meravigliosi componenti funzionali. Hanno reso le classi obsolete per il 90% dei casi d'uso. E chi non si è adeguato, oggi sta pagando il conto.

Perché quel tuo 'codice che funziona' è una bomba a orologeria:

• Il cimitero del this: I componenti funzionali non hanno un this da gestire. Fine del problema. Basta bind, basta scope imprevedibili. Sembra poco? Provate a fare onboarding a un dev junior su una codebase a classi del 2017 e poi ne riparliamo.
• Logica da 'caccia al tesoro': Prima, per capire come funzionava un fetch di dati, dovevi guardare in componentDidMount, poi in componentDidUpdate per i refresh, e infine in componentWillUnmount per la pulizia. Un delirio. Con useEffect, tutto ciò che riguarda un singolo effetto collaterale sta in un posto solo. Pulito. Ordinato. Umano.
• Il mito del riutilizzo: Higher-Order Components? Render Props? Bellissimi esercizi di stile per incasinare l'albero dei componenti e rendere il debug un girone dantesco. I Custom Hooks permettono di estrarre e condividere logica stateful con la stessa semplicità di una funzione. I nostri a Kampala hanno tirato su librerie di Custom Hooks che sono diventati i nostri LEGO. Assembli, configuri, funziona. E passi al problema successivo.

Gli attrezzi del mestiere: poche cose, ma che tagliano.

Non serve imparare a memoria 50 Hooks. Ne bastano una manciata per risolvere il 99% dei problemi. E bisogna sapere dove mettono le mani.

• useState: La base. Ti serve uno stato? Eccolo. Semplice, diretto. Lo usano praticamente tutti (98.8%), perché è l'equivalente del cacciavite a stella: devi averlo, devi saperlo usare.
• useEffect: Il più potente, il più frainteso, il più pericoloso. È il bisturi del chirurgo, ma in mano a un macellaio fa solo danni. Fetching dati, abbonamenti, manipolazioni del DOM... tutto passa da qui. Ma se sbagli l'array delle dipendenze, ti ritrovi con un loop infinito che chiama un'API e ti prosciuga il budget cloud in un pomeriggio. Non chiedeteci come lo sappiamo. Quel 37% di lamentele non arriva a caso.
• useContext: Per farla semplice, è il passaparola ufficiale di React. Evita di dover passare props a mano per dieci livelli di componenti. Utile, ma non abusatene o non capirete più da dove arrivano i dati.
• useRef: Il gancio per aggrapparsi al mondo reale, cioè al DOM. O per tenersi un valore in tasca tra un render e l'altro senza far ridisegnare tutto. Da usare con parsimonia.
• useMemo e useCallback: I gemelli dell'ottimizzazione. Se hai una funzione che fa calcoli pesanti o un componente figlio che non deve ri-renderizzarsi a ogni refuso di battitura del genitore, loro sono i tuoi uomini. Memorizzano roba (risultati di calcoli o funzioni intere) per evitare lavoro inutile. Quasi il 93% dei dev li usa, e quel 7% che non lo fa, probabilmente, ha delle macchine potentissime.

Il Virtual DOM: il trucco di prestigio che ti salva la baracca.

Tutta questa fluidità di React non è magia nera. È un trucco, ben riuscito, che si chiama Virtual DOM (VDOM). E per capirlo, bisogna prima capire quanto è stupido e lento il suo cugino, il Real DOM.

Il Real DOM: il burocrate ministeriale del web

Il DOM del browser è la rappresentazione viva del tuo HTML. È un albero di oggetti. Utile, indispensabile. Ma lento. Terribilmente, inesorabilmente lento. Ogni volta che con JavaScript gli dici 'cambia il colore di questo div', lui non si limita a farlo. No. Si ferma, prende un caffè, ricalcola tutti gli stili CSS, riorganizza il layout dell'intera pagina (reflow) e poi, con comodo, ridisegna lo schermo (repaint). Anche per un cambiamento insignificante. Immaginate un impiegato statale a cui chiedete di cambiare una virgola in un documento di 500 pagine, e lui per sicurezza lo riscrive da capo. Ecco, quello è il Real DOM.

Il Virtual DOM: l'appunto sulla salvietta del bar

React, da furbacchione, ha deciso di non parlare direttamente con il burocrate. Si è creato un suo 'pre-burocrate' in memoria: il Virtual DOM. È una copia leggera, un oggetto JavaScript che rappresenta come *dovrebbe* essere il DOM. Quando qualcosa cambia, React non va a disturbare il Real DOM. Fa così:

1. Scrive l'appunto: Ri-renderizza tutta la UI, ma solo sulla sua copia virtuale, che è velocissima perché è solo un oggetto in memoria.
2. Confronta gli appunti: Prende il nuovo appunto e lo confronta con quello vecchio, di un istante prima. Questo processo si chiama 'diffing'.
3. Va dal burocrate con le idee chiare: Una volta capite le *uniche e sole* differenze (quel div ha cambiato colore, questo paragrafo è stato aggiunto), va dal Real DOM e gli dice: 'Esegui solo queste tre modifiche. Il resto non toccarlo'.

Questo approccio, apparentemente un giro del fumo, è ciò che rende le app React reattive. Invece di riscrivere il romanzo a ogni correzione, cambia solo le parole necessarie. Certo, consuma un po' di memoria in più, ma il guadagno in performance su interfacce complesse è la differenza tra un'auto da corsa e un carretto trainato da buoi.

Noi non vendiamo fuffa. Risolviamo rogne.

Pensaci. La tua PMI a Varese che vuole vendere online in Germania. Ogni lag, ogni scatto, ogni mezzo secondo di attesa è un carrello abbandonato. Ecco perché questa roba non è un vezzo per smanettoni. È la differenza tra fatturare e andare a gambe all'aria.

Qui in ThinkPink abbiamo visto i conti: ignorare questa evoluzione costa, a lungo termine, un 40% in più in sviluppo. Soldi buttati in refactoring che si potevano evitare e in stipendi più alti per trovare i pochi talenti disposti a lavorare su codice vecchio. Belitsoft, in un report del 2026, ha messo nero su bianco che il debito tecnico su React client-side è un calcio negli stinchi alla SEO. L'Interaction to Next Paint (INP), un parametro che a Google piace parecchio, vale il 18% del ranking per gli e-commerce.

Oggi React non è più solo client-side. I Server Components (RSC) sono la normalità, il rendering concorrente è di default. Sfruttare queste cose non è 'bello', è il minimo per non affogare. Il React Compiler, che ottimizza il codice al posto tuo, è un regalo. Ignorarlo è da masochisti.

Noi non ti raccontiamo che 'costruiamo il futuro'. Noi ti ripariamo il presente. Ti spieghiamo come usare un Server Component per non esporre le tue chiavi API come un pivello e come usare il compilatore per far andare più veloce la baracca senza riscrivere tutto. Mettiamo insieme la pignoleria di Rosignano e l'arte di arrangiarsi di Kampala per tirare fuori un prodotto che non sia obsoleto appena messo online.

Il futuro è già passato. E tu dov'eri?

Non è una scommessa, è un dato di fatto. Oggi, quasi il 60% del mercato frontend è React (State of JavaScript 2025). Oltre 11 milioni di siti lo usano. L'80% delle aziende Fortune 500 ci fa girare roba in produzione. 20 milioni di download a settimana da NPM. Questi non sono numeri, sono una sentenza. La maggior parte di chi fa sul serio è già passata oltre.

Continuare con le class components nel 2026 è come andare in giro con il Nokia 3310. Certo, 'funziona'. Ma il mondo, nel frattempo, è andato avanti. E chi rimane indietro, paga. Paga in manutenzione, in performance, in difficoltà a trovare gente brava che abbia voglia di lavorare su un pezzo da museo.

Noi di ThinkPink ti possiamo dare una mano. Ma non aspettarti pacche sulle spalle. Ti diremo che quel codice va buttato, che quell'architettura è da rifare, che è ora di smetterla di mettere pezze e iniziare a costruire come si deve. Siamo i consulenti scomodi che ti dicono la verità. Perché l'alternativa è l'irrilevanza.

Il tuo software arranca? Forse è ora di parlarne.