Le SPA rappresentano un paradigma per le applicazioni web destinato a prendere piede nel corso dei prossimi anni. Non a caso, con ASP.NET MVC 4, nella prossima versione di Visual Studio verrà introdotta la nuova tipologia di applicazione web "ASP.NET Single Page Application (SPA)" o, brevemente, ASP.NET SPA. Peraltro, se nella versione beta di ASP.NET MVC 4 era presente un template per creare una Single Page Application, con il rilascio della versione RC (Release Candidate) il template è stato rimosso. Microsoft ha annunciato che ASP.NET SPA non sarà pronto in tempo con la consegna finale di ASP.NET MVC 4 e quindi ASP.NET SPA è per ora disponibile solo in "preview" come pacchetto su Nuget.

Definizione

Le "Single Page Application" (brevemente SPA) non sono un concetto nuovo. L'idea viene perseguita dagli sviluppatori da diverso tempo e la definizione stessa di SPA è in circolazione almeno dal 2005. Il problema principale delle applicazioni web tradizionali è il ricaricamento dell'intera pagina durante il flusso interattivo dell'utente (l'utente clicca su un link, fa il submit di un form, ecc.), che causa una richiesta verso il server di una pagina HTML intera completamente nuova, senza contare tutte le richieste correlate: immagini, file JavaScript, CSS, ecc.

Il continuo ricaricamento della pagina "disturba" la user experience, in quanto non è possibile nascondere all'utente i tempi di latenza della rete e, di conseguenza, la transizione da una pagina all'altra produce uno sgradevole effetto di "scossa". Inoltre ricaricare la pagina a ogni interazione dell'utente provoca un'inutile ritrasmissione di elementi che, almeno teoricamente, all'atto dell'invio sono già presenti nella pagina e nella memoria del browser. La percezione delle prestazioni di queste applicazioni web è in generale scadente.

Le SPA risolvono questi problemi semplicemente eliminando la necessità di ricaricare la pagina durante la sessione dell'utente. Grazie alla disponibilità sempre più universale di browser che supportano HTML5 (chi più, chi meno), possiamo "spingere" le nostre applicazioni web verso il browser, delegando a JavaScript aspetti come il rendering dell'HTML, la gestione dati e la business logic. Tutte le interazioni e i cambiamenti di stato dell'applicazione sono gestite nel contesto di un singolo documento web.

Ormai da tempo gli sviluppatori web mitigano il problema del ricaricamento totale mediante la tecnica più diffusa: AJAX. Librerie come jQuery aiutano a normalizzare il comportamento di AJAX sui vari browser e hanno permesso a questa tecnica di diventare molto popolare, tanto che jQuery è ormai parte indispensabile di qualunque applicazione ASP.NET (MVC, Web Forms, Web Pages). Non a caso è stata inclusa in tutti i template di Visual Studio. Tuttavia l'uso di AJAX è normalmente limitato a una specifica area della pagina o a una determinata interazione.

In una SPA portiamo questo approccio alla sua massima sintesi, creando un'applicazione che unisce gli aspetti migliori di un'applicazione web e di un'applicazione desktop, pur usando esclusivamente HTML5 e JavaScript. Questo significa che non prevediamo l'uso di nessun plugin specifico (per esempio, Silverlight o Flash), ma ci basiamo solo su tecnologie web standard, implementate nativamente all'interno di qualunque browser (per lo meno nelle versioni più aggiornate).

Esempi di SPA nel "mondo reale"

Per avere un'idea migliore di quello di cui stiamo parlando, facciamo qualche esempio di applicazione nel mondo reale che adotta già questo approccio.

HipMunk, portale per ricerca di voli e soluzioni di viaggio. Navigando tra le sue funzionalità, ci accorgiamo di come tenga traccia dei passi (ovvero dello stato) dell'utente mediante la costruzione dell'URL, non usando uno schema classico di querystring, ma tramite la sequenza di caratteri #! (detta hashbang) (ad esempio: http://www.hipmunk.com/#!Paris+France,May26.May28&1). L'uso degli hashbangs o anche del solo carattere cancelletto # (hash) evita il refresh delle pagina, tuttavia i diversi URL vengono interpretati dal browser come nuove viste e quindi sono aggiunti alla "history". In passato l'uso classico del carattere cancelletto # riguardava quasi esclusivamente la navigazione tra link interni, associati a sezioni diverse di una stessa pagina web. Diversamente, l'accorgimento descritto oggi permette di usare il tasto "Indietro" per tornare alla vista precedente. Se il browser non avesse "memoria" dei nostri passi, ci riporterebbe all'unica pagina precedente di cui ha traccia, probabilmente del tutto fuori dall'applicazione.

Figura 1

Trello, un'innovativa applicazione per la gestione di progetti e collaborazioni online. Nel muoverci tra una scheda e l'altra, in questo caso notiamo che l'URL cambia totalmente e non viene usato il carattere cancelletto #. Questo è reso possibile dalla nuova History API di HTML5 che permette di manipolare la cronologia del browser in modo totale, senza provocare refresh della pagina. La cosa interessante è che, se utilizziamo Trello in Internet Explorer, che non implementa l'API, il sistema fa un cosiddetto fallback, usando ancora una volta il carattere cancelletto #, mantenendo intatte le funzionalità.

Figura 2

Gmail, da sempre un esempio importante di applicazione web a elevata interattività. La versione per tablet si presenta con l'interfaccia "nativa" di una vera e propria app. Google ha infatti impacchettato questa versione in un'applicazione scaricabile dallo store e installata sul device. Qualunque utente comune non sarebbe in grado di accorgersi che quella che sta utilizzando è un'applicazione web piuttostoche un'applicazione nativa. Inoltre l'applicazione consente di scaricare i messaggi in locale per poterli leggere offline, di comporre una e-mail offline per poi inviarla non appena ci si connette.
iCloud.com, per gestire i dati del cloud di Apple via browser.
Windows Azure Management Portal, la nuova versione sostituisce il precedente client Silverlight con una SPA.

Benefici di una SPA

I benefici di una SPA si possono riassumere in cinque punti principali:

un'ottima user experience;
la possibilità di eseguire la nostra applicazione su qualunque dispositivo (desktop, cellulare o tablet);
la capacità di lavorare offline. Diventa infatti più agevole sfruttare le specifiche introdotte con HTML5 per rendere operativa un'applicazione web anche in modalità offline: application cache, local storage, web SQL, ecc.;
la capacità di "impacchettare" la nostra applicazione per distribuirla sui vari app store. Possiamo usare, ad esempio, strumenti di terze parti come PhoneGap;
JavaScript è diventato incredibilmente veloce, grazie agli sforzi e alla competizione intercorsa tra Mozilla Firefox, Google Chrome, Opera e Internet Explorer siamo arrivati ad avere implementazioni che godono di eccellenti ottimizzazioni, tali da far competere JavaScript con un linguaggio compilato, come la compilazione JIT in codice macchina nativo, type-inference e multi-threading. Non a caso sta avendo un ottimo successo Node.js, una piattaforma per creare applicazioni lato server con JavaScript.

Svantaggi di una SPA

Lo svantaggio evidente per un programmatore web che viene da ASP.NET è il fatto che la codebase dell'applicazione è costituita da una porzione molto rilevante di JavaScript, sicuramente molto maggiore rispetto a quanto è probabilmente abituato. Questo aspetto comporta alcune conseguenze, più o meno critiche:

bisogna disporre di una conoscenza approfondita di JavaScript. In molti casi, nelle nostre applicazioni, ci limitiamo ad assemblare librerie e widget jQuery, per ottenere effetti e costruire la UI in modo interattivo. Tuttavia questo approccio è molto riduttivo, non basta essere "utilizzatori" di JavaScript, ma occorre comportarsi da veri e propri "sviluppatori", chiamati a scrivere una propria estesa base di codice;
gli strumenti per lo sviluppo in JavaScript sono meno evoluti rispetto a quelli che abbiamo a disposizione in Visual Studio per il codice server-side. Per fortuna Visual Studio è migliorato moltissimo sotto questo punto di vista e possiamo integrare diversi tool di terze parti (tra cui anche il diffuso ReSharper). Peraltro, per quanto migliorato, il supporto a JavaScript nei tool è ancor'oggi di livello inferiore rispetto a quello per le tecnologie server-side;
dobbiamo strutturare il codice JavaScript nel modo più modulare e pulito possibile, così come siamo già abituati a fare in una tipica applicazione ASP.NET MVC (entities, view model, repository, DTO, classi helper, ecc.), suddividendo il codice in più file, in modo ordinato e strutturato, adoperando il più possibile i design pattern disponibili per JavaScript;
dobbiamo lavorare con tecnologie, librerie e pratiche software in continua evoluzione, che, quindi, posso risultare "instabili", incomplete e che possono presentare incompatibilità sui diversi browser.

Dal momento che non possiamo prescindere dal fatto di dover imparare davvero JavaScript per creare applicazioni web moderne, tuttavia può risultare una scelta molto conveniente l'adozione di CoffeeScript, un linguaggio in stile Ruby/Python che migliora la brevità, la leggibilità del codice e permette uno stile di programmazione più object-oriented (l'uso di classi, l'ereditarietà, ecc.). CoffeeScript viene "compilato" in JavaScript prima di essere usato all'interno della pagina. Al momento è disponibile un'ottima estensione per Visual Studio chiamata Web Workbench che automatizza questa procedura.

Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.