Il Google Web Toolkit (GWT) è un framework open source che permette di ottenere applicazioni front-end complesse basate su JavaScript. GWT offre soluzioni efficienti e riusabili ai problemi che si affrontano tipicamente in AJAX. In questo articolo, proponiamo un‘introduzione a questo utilissimo framework, cercando di metterne in luce le potenzialità.
Tra i diversi tipi di applicazioni e di strumenti messi a disposizione da Google, vi è anche il Google Web Toolkit. GWT si pone come strumento per la creazione di applicazioni web front-end, da scrivere in Java. Come vedremo, ci sono molti punti di contatto con AJAX, ma per poter capire e apprezzare appieno il potenziale del Google Web Toolkit è necessario per prima cosa comprendere i vari aspetti che ne hanno influenzato la nascita. Partiremo quindi con una semplice panoramica sulle notevoli evoluzioni che hanno avuto le interfacce web in ambito di usabilità e di performance.
Già da diverso tempo, ormai, si sviluppano applicazioni sfruttando le tecnologie web, ma negli anni passati ci si è dovuti scontrare ripetutamente con alcuni limiti di questa architettura, in particolare per quanto riguarda due aspetti: l’usabilità finale dell’applicazione (usability) e le sue prestazioni (performance). Questi limiti impedivano di fatto un confronto “ad armi pari” con sistemi tradizionali client-server, di cui il web rappresenta una versione avanzata e distribuita.
Dal momento che proprio su questi due fattori c’erano i maggiori ostacoli, è proprio su performance e usability che ci si è concentrati per apportare i miglioramenti più evidenti.
Performance
Prima dell’avvento di AJAX le comunicazioni tra il client e il server web erano sostanzialmente sincrone: il client doveva recuperare l’intera pagina HTML e ricaricarla ogni volta anche se durante il rendering da parte del browser di questo file venivano effettuate altre richieste per ricavare le risorse necessarie referenziate nel file. Per la creazione di interfacce complesse e che avessero contemporaneamente un minimo di interazione veloce con l’utente, diventava necessario inviare una discreta quantità di dati al client. Ecco spiegato il motivo dei problemi di performance e perche’ questo approccio applicato a sistemi di una certa complessità veniva limitato soprattutto alle intranet aziendali, dove c’era comunque a disposizione una banda sufficiente. Era accettabile infatti all’interno di una LAN aziendale il transito sulla rete di una discreta quantità di dati per la fruizione di una pagina web; ma questo non era accettabile su Internet dove la diffusione della banda larga non era ancora ai livelli attuali.
Usability
Ai problemi di prestazione si associavano problemi di usabilità non secondari. In particolare se ne evidenziavano due piuttosto importanti:
- Dovendo fare i conti con la performance, era necessario trovare un punto di equilibrio che riguardava anche la complessità dell’interfaccia: più questa era complessa, maggiori sarebbero state le ripercussioni su tutto il sistema. Ma tutto ciò limitava anche importanti aspetti dell’esperienza utente: se è vero che le interfacce non devono necessariamente essere “rich”, è anche vero che le rich internet interface hanno in molti casi contribuito a creare delle web application più utilizzabili e più rispondenti ai “comportamenti naturali” dell’utente. Quando queste non erano disponibili, quando le interfacce rich non potevano essere presenti nelle web application, spesso ci si ritrovava in presenza di applicazioni web anche poco usabili.
- Quando l’utente eseguiva quasi ogni operazione, era necessario di conseguenza ricaricare l’intera pagina con le modifiche causate dall’operazione appena eseguita. Questo processo (operazione, invio dei dati, processamento, recupero dei dati dal server, ricostruzione della nuova pagina) aveva come conseguenza dei ritardi, degli “inceppamenti” che non garantivano all’utente una positiva esperienza. Anche qui, l’usabilità veniva messa a dura prova poiche’ l’utente doveva attendere diversi secondi per avere un feedback; non era poi così remota la possibilità che potesse ricevere come risposta, in casi di rallentamenti o congestione della rete, una pagina completamente bianca.
Soluzioni
Le soluzioni sono arrivate sotto forme diverse, ma basate su alcuni concetti comuni. Il primo e più importante concetto è stato di far sì che il risultato derivante dall’elaborazione delle richieste dell’utente andasse a modificare solo una porzione della GUI, senza la necessità che ad ogni operazione si dovesse ricaricare l’intera pagina.
Le forme sotto cui tale soluzione si è presentata sono state inizialmente rappresentate dall’avvento sul mercato di prodotti commerciali come Adobe Flex e dalla comparsa di librerie open source come AJAX.
In breve, Adobe Flex è un prodotto basato su tecnologia flash che permette di creare interfacce rich, con la possibilità di effettuare richieste a service, per poi manipolare con il risultato di tali richieste solo una porzione della GUI. Questo meccanismo ha migliorato la velocità delle risposte perche’, in tali comunicazioni, transita un minor numero di dati: con tali premesse, la qualità del feedback fornito all’utente diventa notevolmente migliore e ne beneficia l’usabilità. Tecnicamente flex ha bisogno che su ogni browser sia installato un flash player, il quale ormai è ampiamente diffuso sulla maggior parte dei browser.
AJAX è una libreria che, tramite JavaScript, permette di effettuare delle chiamate, sincrone o asincrone, a un server. Successivamente, si recupera il risultato derivante dall’elaborazione di queste chiamate e se ne inserisce la presentazione all’interno di una porzione della pagina web già fruita all’utente: insomma, il meccanismo è sempre lo stesso. Tutto ciò ha diversi aspetti positivi, che vanno analizzati singolarmente:
- Si può costruire l’intera GUI web based in passi diversi e asincroni. L’asincronia dei diversi passi, permette di dare un feedback molto più immediato all’utente in quanto le prime richieste che vengono evase producono immediatamente un risultato grafico. Non è quindi più necessario dover attendere tutte le informazioni necessarie alla costruzione dell’intera pagina prima che la pagina sia costruita. Si procede invece un passo alla volta.
- Gli eventi sono scatenati da operazioni dell’utente. Abbiamo già detto che alle chiamate, sincrone o asincrone, corrispondono operazioni mirate solamente alla realizzazione di quanto richiesto dall’utente e che avranno come risultato la manipolazione solamente di una porzione della pagina, diminuendo in tal modo la quantità di dati che transitano sulla rete per singola operazione. Tutto ciò porta a una stretta relazione tra operazione dell’utente e successiva risposta, aumentando nettamente la velocità percepita di risposta. L’esperienza dell’utente diventa più diretta e “responsiva”.
- Gestione dei risultati. Le richieste che vengono effettuate tramite AJAX sono in definitiva solo delle normali richieste HTTP. In quanto tali, presentano un codice di stato, che può essere positivamente testato dalle funzioni JavaScript di callback, con molta semplicità. In tal modo, tramite l’interfaccia stessa, è possibile ottenere un feedback significativo, sia in caso di esito positivo sia in caso di eccezioni.
Conseguenze dell’uso di AJAX
Alla luce di tutte queste migliorie sulle performance e sull’usabilità che ci ha portato AJAX, è diventato abbastanza comune l’uso di interfacce web based di tipo “ricco” : esse sono adesso più naturali e meno dispendiose.
Tuttavia l’uso di applicazioni web e dell’applicazione di AJAX a queste web application ha un difetto non indifferente: l’aumento della quantità di codice client-side necessario a tali sistemi. E oltretutto tale codice diventa ben presto difficilmente strutturabile, a manutenzione complicata e poco riusabile.
Un altro aspetto negativo, che fino ad ora abbiamo volutamente ignorato, è la necessità di produrre codice JavaScript e HTML cross browser, ossia compatibile con tutti i browser: con l’affermarsi di un numero sempre maggiore di browser, nei diversi “modelli” per le diverse piattaforme e con il permanere su molti computer di versioni non aggiornate, questo problema della compatibilità cross browser diventa fondamentale.
- Al crescere della complessità del nostro progetto di applicazione web, basata su AJAX, avremo una diminuzione della manutenibilità del sistema, soprattutto della sezione client side e una sempre maggiore difficoltà nel riuso di tale codice.
- Una notevole porzione del tempo di sviluppo sarà concentrata sulla compatibilità del codice client side con i diversi browser.
Questi due punti rappresentano la causa scatenante del lavoro che ha portato alla nascita del Google Web Toolkit, come indica anche la stessa introduzione nella home page del progetto, che riportiamo liberamente tradotta:
“Oggigiorno, scrivere applicazioni web è un processo noioso e soggetto agli errori. Gli sviluppatori possono arrivare a usare il 90% del tempo dedicato al progetto solo per risolvere le incompatibilità con i vari browser. Inoltre, la creazione, il riuso e la manutenzione di grandi quantità di codice JavaScript e di componenti AJAX può risultare operazione difficile e con molte fragilità”.
GWT
Ed ecco che arriva Google Web Toolkit. GWT ci permette di sviluppare un’applicazione web scrivendo solo codice Java, anche per la parte client, ma utilizzando soluzioni AJAX. Sarà poi il suo apposito compilatore a creare codice HTML e JavaScript per la porzione del nostro progetto identificata come client.
Questo pone rimedio ai due problemi delle applicazioni web basate su AJAX:
- Sviluppando in Java si hanno a disposizioni tutti i concetti propri di questa tecnologia per la strutturazione del codice, per la riusabilità e per la sua manutenibilità.
- Il codice generato dalla compilazione Java2Javascript di GWT sarà compatibile con tutti i browser.
Conclusioni
La realizzazione di applicazioni web con interfacce ricche ha rappresentato negli ultimi anni una piccola rivoluzione nel modo di fruire il web. I problemi di prestazione e usabilità che inizialmente hanno rallentato l’adozione di tale modello sono stati superati grazie a tecnologie quali Adobe Flex e AJAX. AJAX, in particolare, pur rappresentando un decisivo passo avanti ha introdotto a sua volta alcune difficoltà inerenti soprattutto per quanto attiene al codice lato client: la sua strutturazione, la riusabilità e la sua manutenibilità rappresentano un “peso” importante nell’ambito del progetto, e va inoltre considerato il tempo necessario a risolvere tutte le incompatibilità tra codice JavaScript e diversi browser.
Google Web Toolkit si pone come soluzione a questi problemi. Permettendo di scrivere codice in Java, esso pone rimedio agli inconvenienti delle applicazioni web basate su AJAX.
Nei prossimi articoli cominceremo a costruire una semplice applicazione di esempio con GWT: vedremo come si imposta il progetto, quali sono le widget disponibili e come si possono usare, e analizzeremo un primissimo esempio di comunicazione verso il server tramite service RPC.
Riferimenti
[1] Google Web Toolkit: la pagina ufficiale
http://code.google.com/intl/it-IT/webtoolkit/
[2] La documentazione
http://code.google.com/intl/it-IT/webtoolkit/overview.html
[3] RIA: Rich Internet Applications
http://it.wikipedia.org/wiki/Rich_Internet_Application
[4] Ryan Dewsbury, “Google Web Toolkit Applications”, Prentice Hall, 2007
È laureato in Informatica presso l'Università di Roma Tor Vergata. Ha già svolto attività di consulenza presso BNL s.p.a. per 5 anni, occupandosi di C, Perl e Java nell'ambito del risk management. Da due anni svolge attività di consulenza presso il Gruppo Espresso s.p.a. per quanto riguarda il Content Management su piattaforma Java EE.