Il termine Asynchronous Javascript And XML (AJAX) sembra un boccone, ma descrive un concetto semplice: aggiornare parti di una pagina web senza ricaricare il tutto.
Prima di questo, se volevi nuovi dati, aspettavi. Hai fatto clic su un collegamento. Lo schermo si bloccò. La pagina diventò bianca. Poi tutto è stato caricato di nuovo.
AJAX ha cambiato la situazione. Permetteva ai browser di parlare con i server in background. Puoi digitare una query di ricerca e visualizzare immediatamente i risultati. Nessuna ricarica. Nessuno schermo bianco. Solo dati.
Questa non era una nuova invenzione. Si trattava di una combinazione di strumenti esistenti utilizzati in un modo nuovo.
Le tecnologie principali dietro il web design asincrono
AJAX non è una singola tecnologia. È un flusso di lavoro. Si basa sul coordinamento delle tecnologie web standard.
Al centro c’è l’oggetto “XMLHttpRequest”. Questa è una funzionalità JavaScript incorporata. Consente agli script lato client di avviare richieste HTTP (come GET o POST) a un server. Il browser invia la richiesta. Non attende la risposta prima di continuare a visualizzare la pagina. Questa è la parte “asincrona”.
Una volta che il server risponde, JavaScript prende i dati. Lo analizza. Aggiorna il Document Object Model (DOM). L’utente vede il cambiamento senza mai lasciare la pagina.
“AJAX si distingue per un’architettura in cui il codice lato client orchestra il recupero dei dati, l’interpretazione e l’adattamento della visualizzazione in tempo reale, senza ricaricamenti generali o perdita di interattività.”
Per molto tempo questi dati sono arrivati in formato XML. Da qui il nome. XML è dettagliato. È pesante.
Successivamente è subentrato JSON (JavaScript Object Notation). JSON è più leggero. È più facile da elaborare per JavaScript. Framework moderni come jQuery e fetch API hanno reso queste richieste ancora più semplici da gestire. Ma il principio fondamentale rimane: disaccoppiare l’interfaccia utente dalla comunicazione del server.
Perché la compatibilità del browser era importante
All’inizio era difficile.
Non tutti i browser supportano XMLHttpRequest. Oppure lo hanno implementato diversamente.
Internet Explorer 5 e versioni successive alla fine hanno raggiunto. Mozilla Firefox ha seguito l’esempio. Safari e Chrome si sono uniti alla festa più tardi. Oggi, ogni browser moderno supporta queste funzionalità in modo nativo.
Questa convergenza ha consentito agli sviluppatori di creare interazioni complesse che funzionavano ovunque. Prima di questo, dovevi scrivere un codice hacker per far funzionare le cose in Firefox ma non in IE. O viceversa.
Ora, l’attenzione è rivolta alla logica, non agli hack di compatibilità.
Applicazioni del mondo reale che definiscono l’esperienza
Hai usato AJAX migliaia di volte. Probabilmente non ci pensi.
Considera Gmail. Quando apri una casella di posta, non ricarichi la pagina per leggere una nuova email. Il client recupera gli ultimi messaggi in background. Puoi trascinare, eliminare o archiviare. La pagina resta ferma. I dati si aggiornano.
Windows Live Hotmail ha fatto qualcosa di simile all’inizio. Google Maps lo utilizza costantemente. Fai scorrere la mappa. Il browser richiede nuovi riquadri della mappa. Appaiono istantaneamente. Non aspetti il caricamento completo della pagina.
LiveSearch è un classico esempio. Mentre digiti le parole chiave, il motore di ricerca interroga il server. I risultati scendono. Ne fai clic su uno. La pagina passa al risultato. Tutto ciò avviene tramite chiamate AJAX.
Le applicazioni sono infinite.
- Sezioni di commento dinamiche
- Moduli con salvataggio automatico
- Ticker azionari in tempo reale
- Feed di scorrimento infiniti
Queste funzionalità creano una sensazione di “applicazione a pagina singola”. Il sito si comporta più come un’app desktop. Sembra scattante. Sembra vivo.
Lo spostamento verso le applicazioni a pagina singola (SPA)
AJAX ha aperto la strada alle SPA.
In un sito web tradizionale, ogni clic corrisponde al caricamento di una nuova pagina. Il browser scarta il vecchio DOM e ne crea uno nuovo.
In una SPA, viene caricata la pagina iniziale. JavaScript gestisce tutta la navigazione successiva. Scambia i contenuti in modo dinamico. L’URL potrebbe cambiare, ma la pagina non si ricarica.
Ciò richiede un codice lato client più complesso. Devi gestire lo stato. È necessario gestire il routing. Ma l’esperienza dell’utente è superiore.
I social network si basano su questo. Quando pubblichi un aggiornamento di stato, il feed si aggiorna. La tua immagine del profilo viene caricata. Vengono visualizzate le notifiche. Niente di tutto ciò richiede una ricarica completa.
L’eredità dello scambio di dati asincrono
L’acronimo AJAX è un po’ obsoleto. Oggi gli sviluppatori usano raramente il termine. Lo chiamiamo semplicemente “sviluppo web”.
Ma la tecnologia continua a vivere. “XMLHttpRequest” è in gran parte sostituito dall’API “fetch”. JSON è il formato dati standard.
L’impatto è innegabile. Ha aumentato le aspettative degli utenti. Ora ci aspettiamo un feedback immediato. Ci aspettiamo transizioni fluide. Ci aspettiamo che le app Web sembrino software nativi.
Se un sito si ricarica ogni volta che fai clic su un pulsante, sembra rotto. Sembra vecchio.
AJAX ha dimostrato che il web può essere qualcosa di più che semplici documenti statici. Potrebbe essere una piattaforma per applicazioni complesse e interattive.
L’evoluzione non si è fermata qui. Framework come React, Angular e Vue si sono basati su queste basi. Automatizzano gli aggiornamenti del DOM. Gestiscono lo Stato.
Ma l’idea centrale è la stessa.
Parla con il server in background. Aggiorna lo schermo. Mantieni l’utente in movimento.
Lo stiamo ancora perfezionando. Pergamene infinite. Collaborazione in tempo reale. Anteprime dal vivo. Le possibilità rimangono in gran parte inutilizzate.
Cosa verrà dopo? Probabilmente meno clic. Più streaming. Più immediatezza.
La pagina resta. I dati si spostano.
AJAX non è magico. È un compromesso.
Ottieni velocità. Ottieni interfacce utente fluide. Ma ti viene anche il mal di testa.
Il più grande punto di attrito non è il codice. È sicurezza. Nello specifico, la Same Origin Policy (SOP). Per impostazione predefinita, i browser bloccano le richieste AJAX. Parlano solo con il dominio su cui si trova attualmente l’utente. Ciò impedisce a uno script dannoso su “evil.com” di rubare dati dal sito della tua banca. È un muro duro.
Ma gli sviluppatori dovevano rompere quel muro.
Inserisci CORS (condivisione di risorse multiorigine). È il meccanismo che consente a domini diversi di dialogare tra loro. Lo configuri sul server. Se lo fai in modo sbagliato, esponi i dati. Se lo fai bene, abiliti app moderne e distribuite. L’asticella è alta. La configurazione deve essere rigorosa.
Poi c’è la cronologia del browser.
Quando aggiorni una pagina senza ricaricarla, l’URL non cambia. Oppure lo fa, ma l’utente non lo sa. Premi “indietro”. Non succede nulla. O peggio, la pagina si ricarica e perde tutto lo stato. Ciò rompe il modello mentale dell’utente.
Devi aggiustarlo.
Gestisci esplicitamente lo stack della cronologia. Utilizza l’API cronologia HTML5. Stati push. Ascolta i popstate. È noioso. È necessario. Prima di allora, le persone usavano gli hashbang (#! ). Ha funzionato. Ma era complicato.
L’accessibilità è un’altra trappola.
Il contenuto dinamico non sempre si annuncia agli screen reader. Se sostituisci il testo tramite AJAX, la tecnologia assistiva potrebbe non notarlo. È necessario aggiornare gli attributi ARIA. Devi innescare eventi. Altrimenti, stai costruendo un sito che funzioni solo per gli utenti del mouse.
Il panorama sta cambiando.
fetch prende il posto delle richieste XHR grezze. Utilizza Promesse. È più pulito. È moderno. I WebSocket aggiungono comunicazione bidirezionale in tempo reale. Non hai più bisogno di sondaggi. Ricevi aggiornamenti push.
Ma AJAX è ancora la base.
Ha introdotto il modello. Asincrono. Modulare. Non bloccante.
La nuvola si mosse. Il cellulare ha preso il sopravvento. Le Progressive Web App (PWA) richiedevano funzionalità offline e velocità. Tutti si appoggiano a questi principi fondamentali.
L’AJAX è morto? No.
È solo lo strato sotto gli strumenti più recenti. La sala macchine.
Gli sviluppatori continuano a ottimizzarlo. Hanno ancora a cuore la gestione statale che ci ha costretto a risolvere. L’innovazione nell’ingegneria delle interfacce? È costruito su quel fondamento storico.
Continuiamo a perfezionare l’esperienza. L’obiettivo rimane lo stesso.
Veloce. Reattivo. Discreto.
Ma la posta in gioco adesso è più alta. La sicurezza è più stretta. Gli utenti si aspettano un comportamento da nativo. E il codice deve essere accessibile a tutti.
È un atto di equilibrio costante. Uno che non finisci mai davvero.
