Sia il Dynamic HTML che Active Server Pages raccolgono enorme attenzione tra gli sviluppatori di tecnologie web. Eppure non ricordo di aver visto nessuno soffermarsi su quanto potenti queste tecnologie possano essere nel momento in cui sono usate insieme.
Per qualche strano motivo è molto raro trovare sviluppatori che si intendano di sviluppo web sia sul lato server che sul lato client. Chi si occupa di ASP è spesso impegnato a interfacciarsi con i database, a installare componenti e a farli funzionare, ma si limita a banali tabelle e qualche form quando si tratta di publicare i dati e implementare l'interfaccia al sistema.
Similmente, fin troppo spesso anche grandissimi guru di JavaScript e DHTML ignorano ASP e ogni forma di architettura 'alla CGI' , come se si trattasse di roba da nerd all'ultimo stadio, e non di una tecnologia in grado di produrre insieme al DHTML interfacce utenti di altissima qualità.
In questo articolo non approfondirò in maniera particolare nè le tecniche ASP, nè entrerò troppo profondamente nei dettagli del componente DHTML utilizzato.

Ciò che mi preme evidenziare, infatti, è la sinergia tra queste due tecnologie.
Esistono ottimi siti che spiegano le tecninche più avanzate sia di ASP che di DHTML in tutte le sue forme: soffermarsi in dettaglio su questi argomenti significherebbe solo fare dei tutorial per quei poverelli che, pur lavorando con Internet, hanno problemi con la lingua inglese.
L'unione di ASP e DHTML ha ottime possibilità di realizzare ciò che per anni Java ci ha promesso, ma non ci ha dato!

Le Java applet sono state una grande delusione sia per quanto riguarda la parte multimediale del web che la facilità di sviluppo di applicazioni client-server basate su HTTP.
Mi soffermo su Java, dal momento che l'analisi delle debolezze di Java ci aiuta a capire dove il connubio DHTML/ASP riesce meglio.
Oramai anche gli sviluppatori che negli anni hanno cercato di costruire le loro fortune su Java hanno rinunciato a difendere le applet e si arrocano sulle (reali o presunte) potenzialità che Java ha sul server.
A mio parere le ragioni del fallimento di Java sul client sono abbastanza chiare: Java è un linguaggio compilato che necessita di una Virtual Machine per girare.
Questo implica che Java sia, quasi per definizione, abbastanza isolato dal resto della pagina che lo contiene, quindi, tutto ciò che può essere creato con semplice HTML non conta più: Java si ricava un rettangolino e tutto avviene lì.
Naturalmente questo costringe il programmatore a ridefinire all'interno della applet tutti i meccanismi e le risorse di cui una applet ha bisogno. Ciò si è tradotto assai spesso nella necessità di implementare, per così dire, le fondamenta per ogni nuova applet non banale.
Gli strumenti di sviluppo che cercano di ovviare a questi problemi finiscono inevitabilmente per infarcire ogni applet con librerie e codice che impiega troppo tempo a raggiungere il client e troppo tempo a partire una volta che l'applet è stata trasferita nella sua interezza. In breve, è un pò come se ogni applet non avesse la possibilità di andare in albergo nei suoi peregrinaggi, ma fosse costretta a portarsi dietro una gigantesca roulotte con dentro ogni cosa di cui ha bisogno per far mostra delle sue potenzialità. È abbastanza chiaro che, per quanto la roulette possa essere migliorata, molto difficilmente possa competere con la comodità di un hotel in cui tutti i servizi e le comodità già esistono.

Questi sono i difetti principali delle applet, ma ce ne sono anche altri e non da poco:

• la promessa mancata di far girare tutte le applet allo stesso modo su diversi browsers e su diversi sistemi.
• La learning curve impressionante che rende difficile sviluppare applet nuove senza una buona conoscenza ed una grande esperienza.
• La difficoltá di cambiare il design di un applet senza bisogno di un programmatore (o, in casi estremi, del programmatore originale!)

Alla luce di questo, appare abbastanza chiaro che l'intero concetto alla base delle applet era condannato al fallimento. Le Java applet sono state un vicolo cieco: la mia previsione é che gli stessi goal saranno raggiunti dal DHTML usato in congiunzione con ASP o altre tecnologie lato server basate sullo stesso paradigma.

Ai miei colleghi che mi chiedono quanto tempo occorra per imparare il DHTML, rispondo che, in un certo senso, lo conoscono già: io ho scritto la mia prima pagina HTML nel '94 e ho cominciato con JavaScript prima che sapessi cosa fosse il Document object Model (DOM). Contrariamente a Java, Visual Basic e altri, DHTML non è un linguaggio, ma piuttosto un insieme di tecnologie che funzionano insieme. In questo senso il DHTML esiste praticamente dall'inizio del web, benchè il termine sia stato coniato nel '96.
In pratica, ogni volta che carichiamo una pagina HTML, il browser ne mantiene una rappresentazione interna e lascia che certe proprietà siano modificate dinamicamente tramite scripting (JavaScript o VBScript). Netscape 2 permetteva di validare e modificare dinamicamente ciò che l'utente aveva digitato nei form. In Netscape 3, era possibile modificare dinamicamente un'immagine del documento corrente. Successivamente i browser ci hanno permesso di modificare dinamicamente gli stili, le posizioni dei layer, la visibilità di elementi inseriti nei flusso stesso del documento, eccetera.
Con Internet Explorer 5 il controllo di tutti gli elementi è oramai totale. Netscape 5 offrirà esattamente le stesse possibilità, anche se qualche differenza a livello di DOM ancora esisterà.
Il chiaro vantaggio del DHTML è la possibilità per l'utente di interagire con la pagina senza che sia costretto a sorbirsi il viaggio di andata e ritorno col server: l'interattività del sistema ne risulta assai migliorata, cosi' come, trasferendo la logica dal server al client, il carico del server diminuisce notevolmente.
Purtroppo almeno per un anno, chi sviluppa per internet dovrà pensare ai vecchi browser, per cui le cose non saranno totalmente rose e fiori, ma il futuro è chiaro.