Applicazioni in rete dal 1991 al 2025: guida breve

Il CGI nel 1993 ha spostato il calcolo dal browser al server: la pagina non conteneva più solo testo, ma una richiesta che un programma sul server elaborava e restituiva come HTML. Ajax, formalizzato nel 2005, ha permesso di aggiornare una parte della pagina senza ricaricarla, mentre i service worker dal 2015 fanno funzionare l'applicazione anche offline e in background. In mezzo ci sono il web annunciato nel 1991, JavaScript nel 1995 e il responsive design nel 2010.

Che cosa ha cambiato il CGI nel 1993?

Prima del CGI, un server web consegnava file statici: l'utente chiedeva un indirizzo e riceveva un documento già scritto. Il CGI, Common Gateway Interface, ha introdotto un contratto tra il server e un programma esterno. Il server passa al programma i dati della richiesta, il programma li elabora e restituisce una risposta, di solito HTML. Il calcolo avviene sul server, non sulla macchina dell'utente.

La conseguenza pratica è che una pagina può dipendere da ciò che l'utente ha scritto in un modulo. Un motore di ricerca, un carrello, un archivio con parametri nell'URL: tutti questi casi diventano possibili perché qualcosa sul server legge l'input e costruisce la risposta al momento. Il web smette di essere una biblioteca di file e comincia a comportarsi come un'applicazione.

Il limite è nel modello: ogni interazione richiede una nuova richiesta e una nuova pagina. Il browser resta un visualizzatore, il server fa tutto il lavoro. Questa separazione è la base su cui si costruiranno i passaggi successivi, dal web del 1991 in poi. Per chi vuole seguire la cronologia completa, il dossier su storia delle applicazioni in rete raccoglie le tappe dal 1990 al 2025 con i concetti di ogni periodo.

Come è nato Ajax senza ricaricare la pagina?

Ajax non è una tecnologia nata in un giorno, ma un nome dato nel 2005 a un insieme di pratiche già in uso. L'idea è semplice: il browser può chiedere dati al server in secondo piano, riceverli in un formato leggero e aggiornare solo una parte del documento. La pagina resta quella che l'utente sta guardando, mentre i dati cambiano sotto.

Il meccanismo si appoggia a un oggetto del browser capace di fare richieste HTTP fuori dal normale caricamento della pagina. Il server risponde con XML o, più spesso, con testo semplice o JSON. JavaScript legge la risposta e modifica il DOM, cioè la struttura della pagina. Non c'è ricarica completa, non c'è perdita di stato nel modulo, non c'è schermata bianca.

Il passaggio culturale è che il browser diventa una piattaforma di esecuzione, non solo un lettore di documenti. Le applicazioni iniziano a somigliare a programmi desktop: mappe che si spostano, caselle che si completano mentre si digita, liste che si aggiornano da sole. Il web del 2000-2009 è questo: motori riscritti per essere più veloci e un modello di interazione che non dipende più dal ciclo richiesta-risposta completo.

Che cosa permettono i service worker dal 2015?

Un service worker è un programma che il browser esegue separatamente dalla pagina, in background. Non ha accesso diretto al DOM, ma può intercettare le richieste di rete dell'applicazione e decidere come rispondere. Da qui derivano due capacità concrete: la cache e il funzionamento offline.

La prima conseguenza è che l'applicazione può continuare a funzionare senza connessione. Il service worker serve le risorse dalla cache quando la rete non risponde, e le aggiorna quando la rete torna disponibile. La seconda è la possibilità di ricevere eventi in background, come una notifica push, anche quando la pagina non è aperta. La terza è la gestione di una coda di operazioni: un'azione fatta offline può essere inviata al server quando la connessione ritorna.

Questo cambia il rapporto tra applicazione e rete. Fino agli anni 2000 l'applicazione esisteva solo se il server rispondeva. Dal 2015 l'applicazione può esistere sul dispositivo, con la rete come risorsa opzionale. Il responsive design del 2010 aveva già adattato l'interfaccia agli schermi piccoli; i service worker adattano il comportamento alla qualità della connessione.

Perché il responsive design del 2010 è un punto di svolta

Il responsive web design non è solo una questione di CSS. È un cambio di metodo: invece di progettare una pagina per una larghezza fissa, si progettano regole che si adattano allo spazio disponibile. Griglie fluide, immagini flessibili e media query permettono allo stesso documento di funzionare su un monitor, un tablet e un telefono.

Prima del 2010 il mobile web era spesso una versione separata, con un indirizzo diverso e contenuti ridotti. Dopo il 2010 l'idea diventa una sola applicazione, un solo codice, più layout. Questo riduce la duplicazione e rende il web accessibile da dispositivi che nel 1991 non esistevano. È il ponte tra il web dei documenti e il web delle applicazioni mobili.

Il filo che collega 1991, 1995 e 2025

Nel 1991 il web viene annunciato come sistema di documenti collegati. Nel 1995 JavaScript entra nel browser e sposta una parte della logica sul lato dell'utente. Nel 1993 il CGI aveva già spostato il calcolo sul server. Nel 2005 Ajax collega le due parti senza ricaricare la pagina. Nel 2010 il responsive design adatta tutto agli schermi. Nel 2015 i service worker rendono l'applicazione indipendente dalla rete.

Ogni passaggio risolve un limite del precedente. Il CGI risolve la staticità, ma crea il problema delle pagine che si ricaricano. Ajax risolve la ricarica, ma crea il problema della dipendenza dalla connessione. I service worker risolvono la dipendenza, ma creano il problema della gestione della cache e degli aggiornamenti. Non è una storia lineare di progresso, è una storia di compromessi tecnici.

Per chi studia o sviluppa, la parte utile è capire quale problema risolve ogni strumento. Il CGI non è obsoleto: è il modello di ogni API server-side. Ajax non è superato: è il modo in cui il browser parla con il server. I service worker non sono un dettaglio mobile: sono il modo in cui un'applicazione sopravvive a una rete instabile. Il dossier citato sopra copre anche il glossario e una nota sul SEO locale a Montluçon, utile per capire come queste tecniche arrivano sul territorio.

Domande frequenti

Il CGI è ancora usato? Il protocollo classico è raro, ma l'idea di un programma sul server che risponde a una richiesta è alla base di PHP, Python, Node e di qualsiasi API.

Ajax richiede una libreria? No. Le richieste asincrone si possono fare con le API del browser. Le librerie semplificano, non abilitano.

I service worker funzionano su tutti i browser? Sono supportati dai browser moderni, ma richiedono HTTPS e una registrazione esplicita da parte dell'applicazione.

Qual è la data da ricordare? Il 1991 per l'annuncio del web, il 1993 per il CGI, il 1995 per JavaScript, il 2005 per Ajax, il 2010 per il responsive design, il 2015 per i service worker.

Un sito non invecchia bene solo grazie ai contenuti. Icone senza licenza chiara, font caricati male, immagini troppo pesanti e link che si rompono dopo mesi sono i problemi che emergono quando il progetto è già online. Per questo conviene partire da strumenti per siti web che affrontino iconografia accessibile, scale tipografiche fluide, compressione delle immagini e verifica automatica dei collegamenti. La guida interna spiega anche cosa misurano davvero i Core Web Vitals e perché documentare le scelte tecniche evita di rifare lo stesso lavoro sei mesi dopo, quando nessuno ricorda più perché quel font o quel formato è stato scelto.

Fonti: w3.org, it.wikipedia.org, it.wikipedia.org, developer.mozilla.org