Parlando di AJAX con oggettività, si deve ammettere che questo standard, basato sull'oggetto XMLHttpRequest, svolge un solo compito: quello di elaborare dei dati senza dover ricaricare la pagina. Al di là di questo, non ci sono effettivamente dei vantaggi ulteriori nell'usare questa tecnologia. Credo che gran parte del successo di AJAX si deva all'uso che ne hanno fatto alcuni big del Web. Nel loro caso, tuttavia, usare AJAX era una necessità giustificata dal tipo di applicazione sviluppata. Quello a cui invece abbiamo assistito e a cui stiamo assistendo tutt'ora è una sorta di febbre collettiva che spinge gli sviluppatori ad usare AJAX anche dove effettivamente se ne potrebbe fare a meno. Ma si può guarire dall'AJAXite?
Limiti di AJAX
Consideriamo la natura ancora limitata dell'oggetto XMLHttpRequest, la cui standardizzazione da parte del W3C (grazie ad Anne Van Kesteren) è relativamente recente: si tratta di un oggetto che ha pochi metodi e proprietà. Gli sviluppatori in genere non si rendono conto di queste limitazioni perchè usano librerie JavaScript che livellano le differenze tra i browser e usano pattern per arricchire l'arsenale di cui si può disporre.
Ma si tratta pur sempre di aggiustamenti, workaround che non cambiano la realtà di AJAX: per inviare una richiesta con un verbo HTTP si usa sempre l'unico metodo send() a disposizione.
Ancora: la gestione degli errori viene eseguita solo interpretando i codici HTTP dello status della risposta. Utilizzando la console JavaScript si può al limite notare che si è verificato ad esempio un errore 404 (Not Found). Ma lo standard non dispone di metodi per una gestione avanzata degli errori. Come gestire ad esempio un timeout di connessione? Si possono usare i timer JavaScript, che però non sono stati concepiti per questo scopo.
Inoltre lo sviluppatore non ha modo di verificare e gestire le risorse remote (quelle ad esempio in JSONP) se non in modo empirico, per esempio verificando che il contenuto JSON reperito sia effettivamente un oggetto.
In poche parole, tutto è affidato troppo spesso al modo con cui i browser gestiscono internamente le richieste HTTP e i loro errori. Un esempio che mi è capitato spesso di osservare negli ultimi anni è l'evoluzione di un'applicazione come Gmail. Infatti alcuni cambiamenti apportati hanno avuto in passato dei contraccolpi negativi in alcuni browser, primo tra tutti Opera (con le versioni più recenti i problemi sono stati risolti).
Evitare l'AJAXite
AJAX è più una scelta che riguarda l'user experience e il design di un'applicazione che non il suo effettivo funzionamento. In altre parole, un sito funziona anche senza AJAX, solo che il suo funzionamento appare diverso dal punto di vista dell'interazione utente.
Con AJAX la pagina non deve essere ricaricata, senza AJAX si. Tutto qui. Quello che dovete chiedervi, non come sviluppatori ma come utenti, è come i vostri visitatori accoglieranno questa funzionalità.
Oltre all'usabilità c'è anche la questione dell'accessibilità. Sotto questo punto di vista, purtroppo, AJAX andrebbe ancora evitato perchè il livello di supporto delle tecnologie assistive a questo tipo di standard è ancora ben lontano dall'essere soddisfacente.
Riassumendo: usate AJAX, ma non abusatene. Ragionate più a livello di usabilità, interazione utente, design, accessibilità che solo a livello di codice. Onestamente, a livello di codice AJAX è davvero irresistibile. Ma un sito o un'applicazione non sono solo codice.