Dal punto di vista dell’utente finale e del committente in effetti la cosa non potrebbe essere più chiara: noi vogliamo AJAX. Punto. Il problema di identificare l’opzione più adatta è tutto sulle spalle dell’architetto e magari del suo “compare” project manager che approverà la scelta finale. Intanto in questa breve analisi dedicata alle opzioni e agli scenari possibili per AJAX conviene incominciare, guarda un po’, proprio dall’inizio. E cioè dal perché oggi a cinque anni (o giù di lì) dalla “scoperta” dell’acqua calda più fresca della storia dell’homo informaticus siamo ancora a distinguere tra un Web semplice e un Web con AJAX.

Il solito paradosso del Web

Trovo assolutamente incomprensibile che ancora troppi siti oggigiorno costringano le proprie pagine a darsi continuamente una rinfrescata per soddisfare gli utenti. E ne trovo almeno altrettanti che esagerano e che scambiano le possibilità AJAX con l’autorizzazione implicita a fracassare le pazienti pupille del visitatore con animazioni odiose e subdole pubblicità.

AJAX è né più né meno quello che fa Facebook: ovvero utilizzare tecnologie innovative per migliorare la resa delle pagine, semplificando la vita e velocizzando le operazioni. Che poi è spesso la stessa cosa. Dal punto di vista dell’utente, il vero e unico valore aggiunto è nella velocità delle operazioni. Per il resto non c’è molto altro che AJAX porti in dote.

Ma le pagine Web esistono perché dei programmatori le hanno scritte. E quei programmatori hanno usato delle librerie e dei linguaggi. Il paradosso del Web è che mentre a gran voce si chiede velocità, grafica e potenza di calcolo sul browser non si è disposti a rinunciare nemmeno ad un grammo della audience di HTML. E si vede l’installazione di un plugin come Silverlight con lo stesso occhio con cui si rimira prima di aprirla a una lettera rossa-minatoria di una qualche amministrazione dello stato.

Il paradosso è che si vuol fare di più ma usando gli stessi strumenti di 20 anni fa—HTML e JavaScript—che dichiaratamente non erano stati pensati nemmeno lontanamente per fare quello che fanno oggi; figuriamoci quello che si vorrebbe facessero.

E poi arriva AJAX

Con l’arrivo di AJAX ci si è illusi che il cerchio fosse chiuso. In realtà lo strumento base di AJAX—ovvero il buon XMLHttpRequest o XHR per gli amici—è perfetto per piccole cose poco pratiche. Per le pagine vere di applicazioni vere, il buon XHR non basta. E la stessa libreria jQuery è poca roba dal punto di vista di AJAX.

Per fare AJAX seriamente serve innanzitutto un robusto e ampio framework JavaScript che permetta di esporre in modo object-based il contenuto della pagina. Ricordiamo il DOM? È un modello a oggetti che rappresenta la pagina. Solo che il DOM è il DataSet della pagina; ne offre una visione generica basata su collezioni di dati. Il DOM non vede i componenti funzionali quali le griglie, le form, i menu. Il DOM vede solo a bassissimo livello i tag HTML. Per fare AJAX seriamente serve un DOM che sia un domain model specifico per il contenuto della pagina in questione.

Chi lo crea questo domain model?

Librerie di terze parti, da Telerik a ComponentArt passando per Infragistics, Gaiaware e Devxpress lo fanno tutti. Queste librerie partono da controlli server e iniettano un modello a oggetti JavaScript che riflette il modello lato server. Poi ciascuna in modo diverso permettono al programmatore di interagire con questo modello.

E Microsoft?  Non ha (per scelta credo) un modello onnicomprensivo come i succitati vendor. Ma limitatamente ad alcune funzionalità base fa un ottimo lavoro. In particolare con i proxy per servizi Web e con il DataView nella versione prossima versione ASP.NET AJAX 4 in quanto a scenari di data binding.

Implementazione della logica

Programmare  questo domain model richiede codice lato client che può solo essere scritto in JavaScript. Questo codice è di fatto una grossa fetta del presentation layer. Tutto si può fare, ma chiamiamo le cose con il loro nome: le soluzioni rich-client basate sul paradigma AJAX portano a scrivere il presentation layer in JavaScript. È un problema? Bah, dipende. E dai soliti fattori: complessità del codice da scrivere, frequenza di cambiamenti richiesti, dimensione del codice da scrivere. E sostanziale impossibilità di far fronte a queste problematiche usando pattern come MVC o meglio MVP e MVVM. Si può provare certo a fare MVC in JavaScript e magari ci si riesce pure, ma a che costo e con che facilità?

E poi il nostro codice JavaScript ha bisogno di un bello strato di servizi semplici e fatti su misura e anche ben messi in quanto a sicurezza. C’è in sostanza bisogno di un AJAX Service Layer che disaccoppi il front-end AJAX dal middle-tier vero e proprio. L’AJAX Service Layer è uno strato di servizi sostanzialmente REST codificati come WCF in compatibility mode con ASP.NET.  Servizi che poi orchestrano o semplicemente delegano l’esecuzione di operazioni al middle-tier.

Come si vede in questo modello di implementazione di AJAX vi sono soprattutto costi. Il presentation layer va fatto su misura e non con strumenti, come dire,  convenzionali. Il linguaggio è diverso, l’architettura è diversa, i pattern sono diversi. Infilando JavaScript nella pagina perdiamo un sacco in pulizia formale (Separation of Concerns) e in testabilità.

Ecco perché si continua a distinguere Web da Web con AJAX. Ecco perché AJAX non è mai compreso nel prezzo.

AJAX: che fare?

Il partial rendering è sempre un’opzione, sia nella forma offerta da ASP.NET Web Forms sia nelle varianti suggerite da ASP.NET MVC. Il partial rendering non è perfetto; tutt’altro. Ma aggiunge AJAX a costo zero a tutte le applicazioni ASP.NET. E lo fa lato server, senza richiedere refactoring architetturali e senza violentare il codice.

Non è perfetto perché non è implementato in modo soddisfacente e perché comunque soffre di limitazioni precise. Il partial rendering sfrutta il modello applicativo di ASP.NET e non ammette chiamate simultanee perché non saprebbe come gestire il viewstate. Questo è un suo limite inevitabile. Il resto ha a che fare con l’implementazione. Si potrebbe inserire una coda di richieste; si potrebbe rendere il viewstate parziale; si potrebbe evitare il brusco ridisegno del DOM ad ogni richiesta.

Si potrebbe, inoltre, ridefinire meglio il meccanismo dei Page Methods e provare soprattutto a spiegare tutte queste cose molto meglio nella documentazione.

Pur con tutti i suoi difetti, il partial rendering è efficace e costa pochissimo. Non sarà l’opzione migliore ma offre all’utente lo stesso valore aggiunto di soluzioni più sofisticate e costose: abbatte i tempi d’attesa. Il più stupido comando di partial rendering sarà pure 10 volte più lento di una chiamata JSON diretta, ma è in ogni caso 100 volte più veloce e un milione di volte meno frustrante di un refresh totale.

Vi è nel partial rendering una grande idea: iniettare codice JavaScript di nascosto e continuare a nascondere molto del JavaScript necessario al programmatore. Quello che manca sono controlli svegli che sappiano sfruttare al massimo questa caratteristica.

Nel panorama dei vendor vediamo prodotti (ComponentArt) che puntano tutto sulla programmabilità JavaScript e prodotti che prediligono l’aspetto server (Telerik) ma che poi usano partial rendering per dialogare con il client. E in ogni caso abbiamo vendor che offrono controlli di alto livello e quindi un loro modello applicativo. Se ne sposi uno, non te ne liberi facilmente per passare ad altri: devi riscrivere quella parte di codice.

Nel mondo ideale

Nel mondo ideale, io avrei visto Microsoft venirsene fuori con dei controlli identici a prima (TextBox, DropDownList, DataGrid) ma capaci di usare AJAX dal di dentro. Pensate che bello se potessi contrinuare a scrivere i miei Button1_Click ed avere chiamate asincrone AJAX invece di postback. Impossibile? Quello che trovo incredibile è che la tecnologia per questo c’è già. Ricordate le funzionalità callback del GridView di ASP.NET 2.0? E’ AJAX. E lo stesso partial rendering?

Estendere la soluzione a tutti i controlli non era impossibile. E so che per un po’ è stata in discussione. Poi scartata. Oggi questo approccio è riproposto da Gaiaware nella sua libreria Gaia Ajax. E per chi vuole AJAX su Web Forms e non ha tempo da perdere è una magnifica soluzione per rapporto costi/benefici. Date un occhiata a questo link intanto e poi seguite il mio blog per commentare. Altri articoli seguiranno, perché no?