Spesso quando dico che sono uno sviluppatore web, ma non faccio “siti”, le persone rimangono per un attimo disorientate. Con gli strumenti web è possibile creare non solo “siti” ma “applicazioni”, programmi che “fanno qualcosa”, che rispondono all’utente, interagiscono in modo dinamico e sviluppano delle logiche. Il tentativo di creare queste applicazioni web risale ormai da molti anni e ha spinto (sin dagli anni ‘90) allo sviluppo di tecnologie che hanno arricchito la componente “client” dell’applicazione cioé quello che viene eseguito sul browser. Per questo è nato JavaScript e in seguito le tecnologie “a plugin” come Flash o Silverlight. I browser si sono evoluti, hanno aderito agli standard e hanno ottimizzato le loro prestazioni (prima fra tutti Chrome con il engine Javascript V8, talmente performante da divenire la base di una tecnologia Javascript lato-server in grande espansione come node.js - per la quale consiglio di seguire il nuovo blog NodejsItalia). Oggi siamo, a mio avviso, in un momento in cui le tecnologie web “pure” (HTML/JavaScript/CSS) sono vincenti su tutte le tipologie di applicazioni pre-esistenti:
- multipiattaforma (comprese i device mobili, tablet, ecc.)
- cloud (adozione di piattaforme ad elevata scalabilità come Amazon AWS, Azure, ecc. e abbattimento dei costi di infrastruttura e IT)
- sicurezza (operando in modalità HTTPS e con i dati al sicuro nel cloud)
- disponibilità (ho tutto ovunque, mi basta un browser)
Rimangono aperte 3 criticità:
- connettività (se non posso collegarmi al cloud non posso accedere alla mia applicazione)
- storage locale (posso avere la necessità di mantenere delle informazioni “offline”, per motivi di prestazioni o altro)
- responsività (la mia applicazione deve essere interattiva e deve rispondere alle azioni dell’utente senza dover ricaricare schermate di pagina e finestre in un continuo ping pong server-browser “a paginate”)
HTML5 permette di risolvere (purtroppo ancora in modo non omogeneo su tutti browser) tramite le sue nuove API le prime due problematiche.
Riguardo alla terza, in questo periodo specifico stanno emergendo framework e tecniche volte a perfezionare la creazione delle cosidette: Single Page Applications (o SPA)
Il paradigma di applicazione web come singola pagina che “cambia” e “risponde” in base all’interazione dell’utente senza la necessità di doversi mai “ricaricare” ha un suo (mainfesto)[http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php] ed è già nota agli utenti grazie ad applicazioni come Gmail, Google Docs, ecc.
Microsoft, con l’introduzione di ASP.NET MVC 4, ha aggiunto un template specifico per le SPA. Sul sito di ASP.NET è disponibile un tutorial guidato che aiuta a prendere dimestichezza con questo paradigma.
Le due componenti “nuove” che fanno la loro comparsa in questo template sono sicuramente:
- Knockout: un framework Javascript open-source che permette di applicare il pattern Model-View-ViewModel per gestire tutta la UI). Nel template è usato in combinazione con jQuery ma in realtà non ne é dipendente e può essere usato anche da solo o con altri framework (ad es. Mootools, Dojo, ecc.)
- ASP.NET Web API un framework per la creazione di piattaforme di servizi web RESTful, derivato da una costola di WCF e ormai completamente integrato in ASP.NET MVC4
Completano il tutto:
- jQuery (immancabile ormai)
- jQuery UI, con i suo widget (autocomplete, accordion, dialogs, ecc.), gli effetti (che hanno sempre un ottimo impatto visivo e di good feel con l’utente) e temi
- jQuery Validation, con la sua integrazione specifica con ASP.NET MVC, permette di effettuare validazioni di dati lato client in modo molto efficace specificando in classi “lato server” le regole stesse della validazione, così da ottenere una doppia validazione (client+server) del dato stesso.
- Una serie di librerie Javascript contenute in alcuni file (native.history.js, nav.js, upshot.js) che forniscono delle ottime utility per risolvere problemi quali il bookmarking o la navigazione. Di particolare interesse è Upshot (di cui a breve dovrebbe essere pubblicato un sito web specifico), che permette lo scambio dati efficace tra il lato-client e il lato server (l’infrastruttura REST), operando le conversioni tra i dati, il mantenimento dei metadati (ad esempio gli attributi di validazione), il tracking dei cambiamenti sullo stato degli oggetti (in modo da rilevare se un oggetto debba essere o meno risincronizzato con il server) e l’associazione tra le entità (quindi le proprietà di “chiave esterna” e la loro sincronizzazione).
Per rimanere aggiornati il più possibile sullo stato di queste tecniche è utilissimo il blog di Steve Sanderson, il tipo che sta dietro all sviluppo di Knockout (vedi repository del codice su GitHub) e di Upshot,