Enoela

Due parole sulle Rich Internet Application (RIA)

Leggo su ComputerWorld che i ricercatori del gruppo Forrester ci svelano che i “power user” sono piuttosto delusi dalle performance delle applicazioni RIA (Rich Internet Application) che utilizzano AJAX. Le applicazioni web si definiscono “rich” quando le funzionalità della pagina web si arricchiscono di componenti “client-side”, eseguite sul browser. Ci allontaniamo dal paradigma originario del web (come semplice ipertesto finalizzato a pubblicare documenti) utilizzandone le tecnologie per realizzare vere e proprie applicazioni.

Most power users are disappointed with the performance of Rich Internet Applications (RIAs) based on Asynchronous JavaScript with XML, or AJAX, according to a new research report from Forrester Research Inc.

Su questo punto sono abbastanza d’accordo. Condivido lo scetticismo verso AJAX: non è la soluzione a tutti i problemi  e la sua diffusione sta “indebolendo” il web. Le pagine si arricchiscono di componenti client-side (script javascript) e diventano nuovamente vulnerabili alle mille combinazioni sistema operativo/browser. Pensiamo che IE7 è ancora lontano dal soppiantare IE6 e già è apparsa la beta di IE8 che sembra rivoluzionare (dovrebbe, forse, interpretare un po’ meglio gli standard) il comportamento della famiglia di browser più diffusa. Firefox, Safari, Opera, …

Non stiamo ragionando su come viene visualizzata una pagina, se il box model CSS è più o meno conforme allo standard, se l’anti-aliasing dei font è più o meno gradevole: se pagine RIA (imbottite di codice javascript) hanno problemi, l’utente non può utilizzarle . L’applicazione non funziona.

Non sono, invece, minimamente d’accordo con il consiglio, da parte dei ricercatori Forrester, a guardare a tecnologie emergenti come Adobe AIR o Microsoft Silverlight.

As a result of the AJAX limitations, the research firm recommended that business users consider emerging next-generation RIA technologies like Adobe AIR from Adobe Systems Inc. and Microsoft Corp.’s Silverlight tool set.

La storia del web, per quanto breve, è lastricata di lapidi a memoria di “rivoluzionarie” soluzioni client side. Belle e potenti, decedute di fronte alla necessità di installare e tenere aggiornati plugin e macchine virtuali.

Esempi “estremi” di soluzioni RIA, note al grande pubblico, sono senza dubbio le Google Application. Ma già da metà degli anni novanta in molti contesti era sorta l’idea di sviluppare applicazioni basate sul web che andassero a sostituire le classiche applicazioni client-server. L’idea di utilizzare applicazioni aziendali senza dover installare, configurare e aggiornare le stazioni di lavoro ha spinto i progettisti software a ridefinire l’architettura delle applicazioni basandosi sull’utilizzo di un browser standard, HTTP e HTML.

Sembrava stupendo. Capacità grafiche illimitate, costi azzerati nella gestione del parco macchine, modernità, semplicità nel portare su public internet parte delle applicazioni inizialmente concepite per lavorare all’interno della rete aziendale (intranet). Ma i primi prototipi hanno messo subito in evidenza quelle limitazioni insite nella semplicità del modello messo a punto da Tim Berners Lee. HTTP e HTML nascono per pubblicare ipertesti e non per realizzare applicazioni a forte interazione con database e, soprattutto transazionali.

HTTP è stateless, i form HTML sono rozzi e praticamente privi di controllo sulla correttezza dei dati inseriti. E poi quel maledetto browser, con i suoi pulsanti di navigazione (back prima di tutti), permette all’utente di aggirare la nostra logica di pagina e far impazzire l’applicazione (Amazon Bug).

Sofisticate tecnologie server side hanno superato le limitazioni di HTTP. Ma HTML?

In nostro soccorso è arrivato di tutto. Java per primo. Nato proprio per “arricchire” le pagine web trasformandole in applicazioni non ha mai sfondato come soluzione client-side.

Sembrava una bella idea. Erano gli anni in cui Bill Gates dichiarava che internet non aveva futuro. Resosi conto dell’abbaglio sacrificò un mesetto di dividendi e piombò su internet e sul web con la furia di chi possiede l’Asia a Risiko. Può sbagliare tutte le mosse che vuole, ma ad ogni turno può riprovarci. Così Microsoft introduce la risposta a Java: ActiveX. Le pagine web possono essere realizzate in Visual Basic utilizzando qualsiasi tipo di widget grafico e costruendo la logica di controllo più sofisticata. Certo. Peccato che le applicazioni web per essere utilizzate richiedevano client configurati con tonnellate di librerie e componenti impossibili da aggiornare … altro che thin client. Un disastro. Gli ActiveX document scompaiono dopo poco tempo e il Gulag aspettava chiunque osasse menzionarli (perfino Wikipedia è piuttosto vaga sull’argomento). Java sopravvive allo scontro, ma non vince.

A fine anni novanta arriva il Dynamic HTML (DHTML): fiumi di inchiostro e alberi sacrificati per rivenderci ciò che già avevamo: HTML, CSS, Javascript e un modello di interazione con il documento (DOM). Le pagine diventano dinamiche, controlliamo il contenuto dei form, ma non siamo mai al sicuro. I browser sono tanti, la parte javascript può andare in errore, ci tocca spesso replicare sul server la logica di controllo dei dati inseriti (anzi, guai a non creare componenti server robuste).

AJAX aggiunge la possibilità di trasferire informazioni da/verso il server in modalità “asincrona” rispetto alla pagina contenitore e senza, quindi, doverla “ricaricare”. L’oggetto XMLHttpRequest ha reso questo possibile con semplicità (quanti artifizi erano necessari, frame nascosti, …) grazie a IE5 che l’ha introdotto (possedere l’Asia a Risiko serve a qualcosa).

Ma allora, se AJAX mi convince poco, perché AIR e Silverlight ancora meno?

AJAX, per quanto debole non richiede componenti aggiuntivi e resta una soluzione tecnologica aperta e standard (tutte le tecnologie coinvolte in AJAX sono standardizzate dal W3C). I “programmi” AJAX sono semplici file di testo, non richiedono compilazione e chiunque può, se vuole, sviluppare librerie e IDE a supporto della programmazione.

I due concorrenti sono proprietari (Adobe e Microsoft, rispettivamente), richiedono librerie e plugin particolari per essere eseguite (più o meno come il Flash). I componenti vanno scritti e “compilati” usando IDE proprietari (non so se gratuiti o meno). E, se stiamo parlando di applicazioni, questi componenti dovranno essere scaricati sul browser (agendo sui criteri di protezione: quanti utenti capiscono cosa stanno facendo?) e installati, più o meno come applet java. E gli aggiornamenti software? Quando le macchine virtuali/plugin andranno aggiornate? E soprattutto, quando i componenti stessi andranno aggiornati? E’ un film già visto con ActiveX document: resta utopia pensare che il browser “aiutato” dall’utente sia in grado di aggiornare correttamente l’applicazione. Viene meno il vantaggio di usare il browser come client. Allora torniamo alle classiche applicazioni client/server con thick client.

AJAX mi intriga e in esso, ma soprattutto in librerie potenti e robuste come jQuery, per esempio, scommetterei comunque se dovessi imbarcarmi nello sviluppo di RIA.

PS. Il rapporto di Forrester non l’ho letto. Qui c’é il sommario. Costerebbe  775$. Mi riprometto di fare qualche esperimento con AIR e SilverLight, ma i dubbi sulle modalità di aggiornamento sarà difficile fugarli.