Ciao, e benvenuto nella nona puntata della nona stagione. Nelle scorse puntate abbiamo visto l'intelligenza dell'applicazione spostarsi tutta dentro il browser, con le applicazioni a pagina singola, i framework, gli strumenti. Oggi raccontiamo un capitolo affascinante e sorprendente: il ritorno al server. Il momento in cui il pendolo, spinto fino in fondo verso il browser, cominciò a tornare indietro, e il server, che sembrava ormai un semplice fornitore di dati, riconquistò un ruolo di primo piano. È la storia di come il frontend imparò a non fidarsi delle soluzioni assolute.
Ricapitoliamo la situazione, perché il ritorno abbia senso. Con le applicazioni a pagina singola, avevamo spostato tutto nel browser: il server mandava una pagina quasi vuota, e JavaScript costruiva l'intera esperienza dal lato dell'utente. Sembrava il punto d'arrivo, la soluzione definitiva. Ma, come avevamo anticipato, questo modello portava con sé alcuni problemi seri, che all'inizio si tolleravano nell'entusiasmo, ma che col tempo divennero impossibili da ignorare. E furono proprio questi problemi a far tornare indietro il pendolo.
Vediamo questi problemi, perché sono il motore di tutta la puntata. Il primo: la lentezza del primo caricamento. Se tutta l'applicazione vive nel browser, la prima volta che apri il sito devi scaricare una grande quantità di codice prima di vedere qualcosa. Su una connessione lenta o un telefono modesto, l'utente fissava una pagina vuota per secondi preziosi, mentre tutto si scaricava e si avviava. In un mondo in cui l'attesa fa scappare le persone, questo era un difetto grave. Il modello tutto-nel-browser era veloce dopo, ma lento all'inizio, e la prima impressione conta enormemente.
Il secondo problema era l'invisibilità. Ricordi che i motori di ricerca, e altri sistemi automatici, si aspettano di ricevere pagine con il contenuto già dentro, per poterlo leggere. Ma un'applicazione a pagina singola manda una pagina vuota, che si riempie solo dopo, grazie a JavaScript. Per questi sistemi, spesso, la pagina appariva vuota, priva di contenuto. Questo era disastroso per la trovabilità di un sito: potevi avere l'applicazione più bella del mondo, ma se i motori di ricerca la vedevano vuota, era come se non esistesse. Un problema economicamente enorme per moltissimi siti.
Da questi problemi nacque una riscoperta, che è il cuore della puntata: e se lasciassimo che sia di nuovo il server a costruire la pagina già pronta, almeno la prima volta? L'idea era di far generare al server la pagina con il contenuto già dentro, come ai vecchi tempi, così che arrivasse al browser già visibile e leggibile, subito, sia per l'utente sia per i motori di ricerca. E poi, una volta caricata, l'applicazione nel browser si attivava e prendeva il comando, offrendo la fluidità di sempre. Il meglio dei due mondi: la partenza rapida e visibile del vecchio modello, unita alla fluidità del nuovo.
Questa idea di far costruire di nuovo la pagina al server, ma in modo moderno e integrato con i framework a componenti, diede origine a una nuova categoria di strumenti, che divennero centrali nel frontend degli ultimi anni. Sono strumenti che gestiscono in modo elegante questa collaborazione tra server e browser: il server prepara la pagina già pronta, il browser la anima. Presero il posto di semplici framework e divennero il modo predefinito di costruire applicazioni serie, proprio perché risolvevano i problemi del modello tutto-nel-browser senza rinunciare ai suoi vantaggi.
Con questi strumenti si aprì anche un ventaglio di possibilità intermedie, ed è interessante coglierne lo spirito più che i dettagli. Ci si rese conto che non tutto deve stare per forza tutto sul server o tutto sul browser: si poteva scegliere, pezzo per pezzo, dove far avvenire il lavoro. Alcune parti generate una volta e valide per tutti, altre costruite su misura al momento, altre ancora animate nel browser. Il frontend imparò a mescolare gli approcci con finezza, scegliendo per ogni pezzo la strategia migliore. Da una guerra di modelli assoluti si passò a una sapiente combinazione di tecniche.
E qui c'è la lezione profonda di questa puntata, che riprende un tema della stagione sul CSS: la storia della tecnologia è un pendolo. All'inizio tutto stava sul server. Poi il pendolo spinse tutto nel browser, con le applicazioni a pagina singola. Ora è tornato verso un equilibrio, in cui server e browser collaborano, ciascuno facendo ciò in cui è più bravo. Non è un tornare indietro, ma una sintesi più matura: si sono presi gli insegnamenti di entrambi gli estremi. È la dimostrazione che raramente esiste una soluzione assoluta; di solito, la saggezza sta nel combinare, nel bilanciare, nell'adattare al contesto.
Per oggi ci fermiamo qui. Il modello tutto-nel-browser delle applicazioni a pagina singola aveva due difetti gravi: il primo caricamento lento e l'invisibilità ai motori di ricerca. Da questi problemi nacque il ritorno al server: far costruire di nuovo al server la pagina già pronta, per una partenza rapida e visibile, lasciando poi che il browser la animi. Nacquero strumenti moderni per orchestrare questa collaborazione, e la libertà di scegliere, pezzo per pezzo, dove far avvenire il lavoro. Il pendolo era tornato verso un equilibrio maturo. Nella prossima e ultima puntata tiriamo le somme e guardiamo lontano. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.