React ha vinto. E adesso?

React ha vinto. Non è una provocazione: è una constatazione. Le offerte di lavoro lo danno per scontato, i designer ragionano in componenti, le alternative si descrivono in rapporto a lui. Io ci lavoro ogni settimana e ci lavoro volentieri.

Ma quando una tecnologia vince, smette di dover convincere. E quando smette di dover convincere, i suoi costi diventano invisibili — non perché siano spariti, ma perché nessuno li mette più in conto. Questi sono i tre che pago più spesso.

Spediamo la pagina due volte

Il server renderizza l'HTML. Il browser lo mostra. Poi arriva il JavaScript — l'intera applicazione, componenti, logica, stato — e React rifà da capo il lavoro appena fatto, per "idratare" ciò che l'utente sta già leggendo. La pagina viaggia due volte: una come documento, una come programma che di quel documento riesegue il rendering.

Per un'app densa di interazione è un prezzo sensato. Ma lo paghiamo ovunque: sulla pagina dei contatti, sull'articolo di blog, sulla scheda prodotto che ha un bottone in croce. Il telefono di fascia media dell'utente medio esegue centinaia di kilobyte di JavaScript per rendere cliccabile ciò che era già visibile. Se ti sei mai chiesto perché un sito "veloce" in locale sembra lento in metropolitana: spesso è questo. Non la rete. Il lavoro rifatto.

La domanda che mi faccio sempre più spesso davanti a una pagina è banale e scomoda: quanta di questa interattività esiste davvero? E perché il default è pagare per tutta quella che non esiste?

useEffect è il posto dove va a vivere ciò che non ha casa

Ogni codebase React che ho ereditato ha lo stesso quartiere malfamato: effetti che sincronizzano stato con stato, effetti che rincorrono props, effetti con dipendenze messe a tacere perché il linter "esagerava". Non è colpa degli sviluppatori. È che il modello dice "la UI è funzione dello stato", e poi tutto ciò che non è UI — fetch, sottoscrizioni, sincronizzazioni, il mondo — deve infilarsi in un unico meccanismo pensato per gli effetti collaterali del rendering.

Il team di React lo sa: la documentazione moderna dedica pagine intere a spiegare quando non usare useEffect. Quando la guida ufficiale di uno strumento spende così tanto spazio a elencare i modi per non usarlo, lo strumento sta facendo un lavoro che non è il suo, al posto di qualcosa che manca.

Il paradigma cambia ogni pochi anni, e lo chiamano stabilità

Classi, poi hook, ora componenti server: tre modi profondamente diversi di scrivere la stessa applicazione nel giro di dieci anni, ciascuno presentato come il futuro, ciascuno con la sua migrazione a carico tuo. I componenti server, in particolare, hanno spaccato l'ecosistema in due React: uno che gira sul server e uno nel browser, con una frontiera — "use client" — che ogni sviluppatore deve presidiare a mano, file per file.

Il punto non è che le idee siano sbagliate. Alcune sono ottime. Il punto è il costo composto: librerie da riscrivere, tutorial che invecchiano in sei mesi, team che passano interi trimestri a migrare invece che a costruire. La stabilità di un ecosistema non si misura da quanto è popolare, ma da quanto vale un anno di esperienza dopo tre anni. In React, sempre meno.

Cosa me ne faccio, di questo conto

Non smetto di usare React: per interfacce dense e con molto stato resta il compromesso migliore che conosco. Ma ho smesso di trattare i suoi default come leggi di natura. L'idratazione totale non è un dato di fatto: è una scelta, e su gran parte delle pagine è quella sbagliata. Il JavaScript spedito non è un costo fisso: è una variabile, e andrebbe misurata come misuriamo le query lente.

La prossima volta che apri il tab Network su una tua pagina, fai un esercizio: guarda quanto JavaScript scarichi e chiediti quante di quelle righe servono a ciò che l'utente può effettivamente fare lì. La distanza tra i due numeri è il margine di cui nessuno parla — ed è enorme.