Ajax e le sue implicazioni client

Nello sviluppo di applicazioni web, negli ultimi anni, ho cercato di portare il più alto numero possibili di controlli applicativi verso il server e scaricare il browser (client) da problemi di incompatibilità e fragili funzioni javascript. Questo mio ragionamento mi ha portato a creare design semplici, funzionali e liberi da grafica o funzionalità client più o meno complesse. A rafforzo di questa pratica, c’è sempre stato poi l’annoso discorso delle velocità (o lentezza) di caricamento di una pagina, compromessa dalla quantità di immagini, filmati e flusso di dati (ad esempio se si deve visualizzare una tabella complessa con molte colonne e righe). Con l’invio di un form o il click di un link, si server deve rimandare l’intero contenuto della pagina e questo incide sul design, sulla tecnologia adottata, sulle prestazioni del server, sull’occupazione della banda (hai un contratto a traffico? navighi da un pda? da un cellulare? allora sai di cosa parlo…).
Da qualche hanno è stato introdotto il concetto di richiesta asincrona, ossia l’invio di una richiesta inviata al broswer senza che l’intero contenuto della pagina venga aggiornato (sincronia) con la risposta del server. Questo messaggio di ritorno viene gestito in background e poi manipolato apportunamente per poi essere mostrato all’utente. Questa tecnica è chiamata Ajax.
Nelle ultime settimane mi sto dedicando intensamente allo sviluppo di un’altra applicazione web e questa volta ho deciso di sprerimentare anche io, con le mie mani, Ajax ed introdurre alcune funzionalità di sicuro impatto funzionale e di miglioramento dell’usabilità per l’utente.
(nota tecnica: l’applicazione viene sviluppata utilizzando Java, Struts, Hibernate, Postgresql e Ajax).
La decisione di implemetare Ajax sulle pagine, mi sta portando però ad un uso intenso di javascript, con il risultato che molti controlli però li devo portare verso il client. E’ una soluzione che non mi rende felicissimo, ma ne sono in qualche modo obbligato, perchè la non sincronia tra le richieste (e quindi la relativa storia temporale) non è facilmente ricreabile e tracciabile (lo sarebbe, ma non voglio appoggiarmi ancora di più su javascript, ne tanto meno usare i cookies). Per questo devo scendere a compromessi applicativi, ma devo dire che l’esperienza generata dall’uso di un’applicazione web in cui si applica Ajax è veramente superiore al piccolo fastidio nel dover cambiare alcuni paradigmi di sviluppo su cui ho basato nell’ultimi anni lo sviluppo delle mie applicazioni.
Visto che ho citato anche Hibernate, ammetto che anche l’utilizzo di questo ORM mi ha semplificato a livelli astronomici lo sviluppo in java e la gestione dei dati.
Ho completamente rivoluzionato il mio modo di scrivere codice. E ne sono contento. 🙂