Ho scritto un manuale su React. Ora costruisco senza React

Da quando ho cominciato a sviluppare con l’intelligenza artificiale al fianco, una fetta grossa del mio lavoro se n’è andata sui siti web. Soprattutto su quello di Runtime Radio, che ha una storia lunga e molto precisa. Anzi, a essere onesti è stato proprio l’immobilismo del vecchio sito storico a spingermi dentro un mestiere che conoscevo solo di striscio. Stava fermo da anni, e guardarlo fermo mi dava un fastidio quasi fisico.

Poi mi sono innamorato di React. E adesso, un manuale e parecchie cicatrici dopo, due dei miei siti sono stati rifatti da zero senza React, compreso questo che state leggendo. Vale la pena raccontare come ci sono arrivato, perché non è una moda che passa: è un conto che a un certo punto è arrivato in tavola.

L’innamoramento, e il suo effetto collaterale

React fa una cosa e la fa benissimo: tiene in ordine l’interfaccia. Tu descrivi come devono stare le cose sullo schermo, lui si occupa di farcele stare mentre i dati cambiano sotto. Per uno che veniva dalla radio e dalla scrittura è stata una rivelazione.

Il problema l’ho visto tardi, e l’ho visto da una porta laterale. React sbilancia i progetti: li spinge tutti a diventare applicazioni. Non è un caso che i miei videogiochi in sviluppo abbiano finito per avere lo stesso identico stack dei miei siti, React più TypeScript più Tailwind e via elencando. Quando la stessa cassetta degli attrezzi ti serve per un portfolio e per un’avventura grafica, dovresti fermarti un attimo e chiederti se non stai costruendo tutto con la forma di una app, compreso quello che una app non è.

I siti crescono e chiedono un database

Intanto i siti crescevano, quello di Runtime prima di tutti, e più crescevano più diventava chiaro che le pagine statiche non bastavano. Serviva roba dinamica: contenuti che cambiano senza toccare il codice, archivi, categorie, un pannello per scrivere. Da lì il database, SQLite per cominciare e MySQL dopo, e il PHP a fare da schiena.

Ci ho creduto al punto da scriverci un manuale. React + PHP: The Thin Stack, terza edizione, in italiano e in inglese, in vendita da giugno. Non era un pamphlet teorico: era la fotografia di quattro siti veri, con le loro cicatrici, e qui avevo spiegato perché l’avevo scritto. L’idea era semplice e mi sembrava solidissima: siti bellissimi con un mini CMS dentro, React davanti per l’estetica, PHP dietro per i dati, e in mezzo un contratto sottile fra i due.

Quell’idea non ha retto. Ci ha messo mesi, e la crepa è partita dal lato che non stavo guardando.

La prima crepa: farsi leggere da Google

Qui devo spiegare una cosa a chi non fa questo mestiere, perché è il cuore di tutto il discorso.

Un sito costruito con React non arriva al vostro browser come una pagina. Arriva come un programma: il browser scarica il programma, il programma chiede i dati al server, e solo dopo disegna sotto i vostri occhi quello che leggete. Voi non ve ne accorgete, o quasi. Se ne accorge Google, che a quella pagina arriva per primo e trova una scatola vuota.

La soluzione classica, quella che ho descritto nel libro, è una protesi: metti davanti al sito un file PHP che riconosce i motori di ricerca e a loro, e solo a loro, serve la pagina già scritta. Funziona. È in produzione da mesi su siti veri. E costa sei cose che il capitolo che la spiega elenca una per una, presentandole come inevitabili:

• gli indirizzi delle pagine sono scritti due volte, in due linguaggi diversi, e nessuno obbliga le due copie a restare d’accordo;
• il ramo per i motori di ricerca ripulisce i testi con uno strumento che toglie i tag ma non guarda gli attributi, e da lì passa roba che non dovrebbe passare;
• ogni visita che si presenta come motore di ricerca costringe il server a interrogare il database: è esattamente la leva con cui Runtime Radio si è preso un attacco, a febbraio;
• se la regola che nasconde le bozze non viene ricopiata in ogni singola interrogazione, un articolo non finito finisce su Google;
• c’è una memoria di appoggio costruita apposta per i motori, che il sito riempie con diligenza e non rilegge mai;
• e le anteprime social, quelle che si vedono quando incolli un link su WhatsApp, vanno costruite a mano una pagina per volta.

Il capitolo 11 è il più lungo dei venti del mio libro. Ed è il capitolo che insegna a costruire quella protesi.

Il capitolo più lungo del mio manuale risolve un problema che si sceglie di avere.

Quel capitolo l’ho scritto io, riga per riga, e per mesi l’ho considerato la parte più solida del lavoro. Poi è bastato mettere in fila le sei righe qui sopra e guardarle: nessuna delle sei parla del PHP. Parlano tutte di React.

Poi è arrivato il progetto di Keyla Damaer

Non chiedetemi altro, ve ne parlerò a tempo debito. Dico solo la parte che riguarda questa storia.

Quel sito ha un vincolo che schiaccia tutti gli altri: gli indirizzi delle pagine devono restare identici a quelli di adesso. Cinquanta pagine, trentanove articoli, una decina di pagine che devono restare pubbliche ma invisibili ai motori. Novanta indirizzi buoni, molti irregolari, da tenere allineati a mano in due linguaggi. La doppia verità delle rotte, che sugli altri siti era un fastidio da manuale, lì diventava il punto preciso in cui il progetto si sarebbe rotto per primo.

L’avvertimento, per la cronaca, era arrivato mesi prima. Il 24 aprile avevo registrato un vocale di sei minuti in cui dicevo, testualmente, che «anche se io dovessi mantenere gli URL non è detto che poi alla fine il sito che stiamo facendo è scansionabile dai bot di Google, e questo è un problema gravissimo che non avevo tenuto in considerazione». La Search Console confermava: sulla carta funziona tutto, in realtà no. Ci sono voluti altri tre mesi e mezzo perché la conclusione diventasse una decisione scritta.

Il 9 agosto l’ho messa nero su bianco. Quel sito si fa tutto in PHP, pubblico e pannello, senza React e senza catena di compilazione. E c’è una ragione che non è tecnica per niente: la committente me l’ha ripetuta in tre email diverse, e la riassumo così: e se un domani tu sparisci, io che faccio? Un progetto in PHP puro si riapre e si modifica fra dieci anni, da chiunque, con qualunque assistente. Un pannello React vuole Node, un’installazione di pacchetti e una ricompilazione per cambiare una virgola. Il costo di quella scelta è rinunciare a riusare componenti già scritti; il guadagno è un sito che sopravvive a chi l’ha fatto.

Il Festival, sei giorni, senza React

La prima applicazione vera è stata il Festival della Canzone Artificiale, rifatto da zero fra il 31 agosto e i primi di settembre: dodici versioni in sei giorni, un motore di gara con televoto e giuria, il JavaScript ridotto a dodici chilobyte in un file solo. Ne ho scritto un devlog intero, e non lo ripeto qui. Quello che conta per questo articolo è che ha funzionato, e che ha funzionato meglio di quanto mi aspettassi.

E poi questo sito, quello che state leggendo

Il 7 settembre è toccato a lui. Tre proposte di design disegnate prima di scrivere una riga di codice, una scelta, e la ricostruzione. Adesso ogni pagina di questo sito esce dal server già fatta, identica per voi e per Googlebot, e senza React da nessuna parte.

I numeri del prima e del dopo dicono la cosa meglio di me.

Prima: venticinque librerie da scaricare per lavorarci, mezzo giga di pacchetti sul mio disco, un pacchetto compilato da un mega e mezzo da caricare a ogni pubblicazione, dodicimila righe di TypeScript sparse in quarantacinque file. E una compilazione obbligatoria a ogni modifica: se si rompeva quella, non pubblicavo.

Adesso: seimilaseicento righe di PHP, cinque file JavaScript per diciotto chilobyte in tutto, nessun pacchetto da installare, nessuna compilazione. Modifico un file, carico quel file, è online.

La verifica che mi interessava davvero, però, era un’altra: centosessantacinque indirizzi su centosessantacinque rispondono ancora, con lo stesso titolo e la stessa descrizione di prima. Nessuna pagina si è persa per strada, nessuna manda altrove. Non è pignoleria: un indirizzo già indicizzato che di colpo risponde «non esiste» costa mesi di posizionamento, e non se ne accorge nessuno finché non è tardi.

Sul resto sarò prudente, perché la sincerità vale più dell’effetto: non vi vengo a raccontare che sono salito in classifica in ventiquattr’ore, sarebbe una balla. Quello che posso dire è che da oggi Google non deve più eseguire niente per leggermi, che non esiste più una versione delle pagine per i robot e una per gli umani, e che quel vantaggio si misura in settimane, non in ore. Vi farò sapere con i dati veri.

Una cosa però si è chiusa subito. Il buco di sicurezza di cui sopra, quello del ramo per i crawler, non l’ho riparato: non può più esistere. Prima c’erano due percorsi che ripulivano i testi, uno nel browser per le persone e uno sul server per i bot, e soltanto uno dei due guardava anche gli attributi. Adesso il percorso è uno solo e passa da una funzione sola. È la differenza fra chiudere una porta e costruire un muro dove la porta non serviva.

«PHP» non vuol dire «sito del 1999»

È il timore che sento più spesso, ed è infondato. L’estetica di un sito non sta in React: sta nel CSS, nei caratteri, nel ritmo dello spazio bianco. Tailwind, per dirne una, è un compilatore che legge file di testo, e gli va bene un file PHP quanto un file TSX. Le transizioni fra le pagine oggi le fa il browser da solo, con strumenti nativi che fino a ieri non c’erano e che pesano zero. I caratteri tipografici li ospito in casa invece di chiederli a Google, così nessuno viene schedato mentre legge una pagina.

Questa cosa nel mio libro non si legge, e non per malizia. Il capitolo sulle dipendenze mette Tailwind in tabella accanto a React, e la vicinanza in un elenco diventa vicinanza di natura. Un lettore che volesse l’estetica senza l’applicazione, nel libro, non trova il permesso di prendersela. Glielo darei volentieri.

Quello che ci ho guadagnato scrivendo

C’è un pezzo di questa storia che vi riguarda più di quanto sembri, perché è il posto da cui esce quello che leggete.

Il pannello di scrittura è stato rifatto anche lui, e adesso l’editor è scritto in casa, senza librerie: incolla il markdown e lo riconosce, ripulisce da solo la roba che arriva da Word e da Google Docs, e soprattutto accetta esattamente quello che il sito accetta. Quindi quello che vedo mentre scrivo è quello che il sito pubblicherà, senza sorprese silenziose. Sopra c’è un riquadro che si chiama «Come esce su Google» e fa vedere il risultato di ricerca mentre lo compongo. Sotto c’è un verificatore che dà un voto su dieci controlli e mi dice, con parole normali, che cosa manca.

Su quel verificatore ho imparato una lezione che mi porto dietro. La versione precedente premiava chi metteva molte etichette. Risultato: duecentotto etichette usate una volta sola, cioè duecentotto archivi con dentro un articolo. Gli incentivi di un pannello sono una specifica anche quando nessuno li ha scritti come tale, e chi li progetta dovrebbe saperlo.

Runtime Radio resta in React, e va benissimo

Non ho tolto React da tutto. Il sito di Runtime Radio ci resta, perché ha un lettore audio che deve continuare a suonare mentre navighi e una diretta che si aggiorna da sola: lì l’applicazione serve davvero, e quello che costa vale quello che compra.

Il punto non è che React sia sbagliato. È che è un gradino alto di una scala, e va salito solo quando ti serve l’altezza. Nel mio libro quella scala esiste sul lato del database, dove racconto tre gradini diversi; sul lato di quello che il lettore vede, invece, i quattro siti del libro stanno tutti sullo stesso, e il libro non lo dice. Mancava il gradino di sotto. Adesso ce l’ho, ci ho costruito sopra due siti e un terzo è in cantiere.

Che ne faccio del manuale

La terza edizione non la tocco e non la rinnego. Descrive bene quello che descrive, e le persone che l’hanno comprata hanno in mano un libro che funziona; ci metterò soltanto una nota che dichiara a quale mese si riferiscono le fotografie dei siti, perché quelle invecchiano in fretta e il resto no.

Il seguito, però, non sarà una quarta edizione: sarebbe un libro che smentisce il proprio titolo per metà delle pagine. Sarà un libro nuovo, e ha già un titolo di lavoro, che è la frase con cui ho aperto il repository del Festival: PHP puro: The Thin Stack senza il thin client. Nelle prossime settimane vi racconterò per bene che cosa cade, che cosa resta e quali porte apre questo mio passo indietro, un pezzo per volta.

Per adesso mi tengo la parte scomoda, che poi è quella che mi fa più simpatia. Ho passato mesi buoni a difendere un’architettura, l’ho messa per iscritto, l’ho venduta in due lingue, e poi l’ho smontata con le mie mani perché i fatti dicevano un’altra cosa. Non mi sembra una figuraccia. Mi sembra il minimo sindacale.

Come diceva qualcuno, la coerenza è importante: sostenerla a ogni costo è da imbecilli.