Ciao, e benvenuto nella quinta puntata della nona stagione. Nella scorsa puntata jQuery aveva reso l'interattività accessibile, ma abbiamo detto che il suo approccio non bastava più quando il Web smetteva di essere fatto di pagine e diventava fatto di applicazioni. Oggi raccontiamo questa svolta enorme, forse la più grande nella storia del frontend: la nascita delle applicazioni a pagina singola, l'idea di costruire un intero programma dentro il browser.
Ricapitoliamo dove eravamo, perché il salto sia chiaro. Fino a questo punto, anche con AJAX e jQuery, il modello mentale era sempre lo stesso: c'erano delle pagine, servite dal server, e su di esse si aggiungeva un po' di interattività. Il server restava il regista: costruiva le pagine e le mandava, e il browser le mostrava, con qualche ritocco dal vivo. Il cuore dell'applicazione, la sua logica, viveva sul server. Il browser era un bravo assistente, ma non il protagonista.
L'idea rivoluzionaria delle applicazioni a pagina singola ribaltò completamente questo modello. Diceva, in sostanza: e se caricassimo una sola volta una pagina quasi vuota, e poi lasciassimo che sia JavaScript, dentro il browser, a costruire e gestire tutta l'applicazione, da cima a fondo, senza mai più ricaricare? Il browser non riceverebbe più pagine già fatte dal server: riceverebbe solo dati, e sarebbe lui a trasformarli in ciò che vedi, a gestire il passaggio da una schermata all'altra, a occuparsi di tutta l'esperienza. In pratica, l'intera applicazione si trasferisce dal server al browser.
Il nome dice tutto: applicazione a pagina singola. Perché, dal punto di vista del browser, la pagina caricata è sempre e solo una. Non si passa più da una pagina all'altra ricaricando; si resta sempre sulla stessa, e JavaScript ne cambia il contenuto per farla sembrare tante schermate diverse. Clicchi su una voce di menù e la schermata cambia, ma la pagina non si è ricaricata: è JavaScript che ha svuotato e ricostruito ciò che vedi. Il browser diventa una tela vuota su cui l'applicazione dipinge continuamente, invece di una successione di fogli stampati.
Perché questa idea fu così attraente da conquistare il mondo? Perché prometteva di rendere le applicazioni web indistinguibili dai programmi installati sul computer. Nessun ricaricamento, nessuna pagina bianca, transizioni istantanee e fluide, un'esperienza reattiva e continua. Era il compimento del sogno di cui parliamo da inizio stagione: rendere il Web vivo come un vero programma. Le applicazioni a pagina singola mantenevano quella promessa in modo radicale, e per un certo periodo sembrarono la risposta definitiva a tutto. Il Web poteva finalmente competere, come esperienza, con le applicazioni native.
Ma questa rivoluzione ebbe una conseguenza profonda, che è il vero cuore di questa puntata: spostò una quantità enorme di lavoro e di responsabilità dal server al browser. Prima, il browser doveva solo mostrare pagine. Ora doveva costruire l'intera applicazione: gestire i dati, decidere cosa mostrare, occuparsi della navigazione, tenere tutto coerente. Compiti che prima vivevano sul server, in un ambiente controllato, ora vivevano nel browser, sul dispositivo di ogni utente. Il frontend, da semplice presentazione, diventava il luogo dove risiedeva la vera complessità dell'applicazione.
E qui il ribaltamento della professione, di cui parliamo da inizio stagione, si compie del tutto. Se l'intera applicazione ora vive nel browser, allora costruirla richiede competenze di programmazione serie, architettura, gestione della complessità: esattamente le cose per cui, un tempo, si rispettavano solo gli sviluppatori del server. Il frontendista smetteva di essere quello che aggiungeva fronzoli e diventava un ingegnere che costruisce applicazioni complesse. Il linguaggio-giocattolo era ora il fondamento su cui poggiavano applicazioni enormi. Il disprezzo di un tempo si trasformava, definitivamente, in rispetto e in richiesta altissima.
Ma sarei disonesto se non dicessi che questa rivoluzione portò anche problemi nuovi, di cui parleremo nelle prossime puntate, perché la storia non è mai un progresso semplice. Mettere tutta l'applicazione nel browser creava nuove difficoltà: la prima volta che aprivi il sito dovevi scaricare tutta l'applicazione, e questo poteva essere lento. Costruire tutto nel browser rendeva le cose invisibili ai motori di ricerca, che si aspettavano pagine già fatte. E gestire un'intera applicazione dentro il browser era di per sé complicatissimo. Ogni soluzione, nella nostra storia, crea i problemi della fase successiva: le applicazioni a pagina singola risolsero il problema della fluidità, ma ne aprirono altri, che avrebbero guidato l'evoluzione degli anni seguenti.
Per oggi ci fermiamo qui. Le applicazioni a pagina singola ribaltarono il modello del Web: invece di ricevere pagine già fatte dal server, il browser carica una sola pagina e lascia che sia JavaScript a costruire e gestire l'intera applicazione, senza mai ricaricare. Questo mantenne il sogno di un Web fluido come i programmi veri, ma spostò tutta la complessità nel browser, completando il ribaltamento della professione: il frontendista diventa ingegnere. E aprì problemi nuovi che avrebbero guidato il futuro. Nella prossima puntata affrontiamo gli strumenti nati per gestire questa complessità: la guerra dei framework. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.