Modern Web Applications: come e quali realizzare?

Negli ultimi 5 anni sono stati coniati diversi termini per rappresentare le applicazioni web in differenti ambiti: Single-Page Applications, Isomorphic/Universal Web Applications, Hybrid Web Applications, Native Web Applications e ultimamente Progressive Web Applications. Ma che differenza c’è tra tutte queste tipologie di applicazioni? Vediamole in dettaglio. SINGLE-PAGE APPLICATIONS Nel 2014 il termine SPA si è consolidato tra gli sviluppatori web grazie ai sempre più utilizzati framework Javascript client-side, come AngularJS, Ember, Vue.js, ExtJS. Questo genere di applicazioni, come suggerisce il nome, “vivono” in una pagina singola (ad esempio nell’index.html), gestendo la navigazione e associando a ogni rotta uno stato. Essendo applicazioni stateful, risulta possibile ripristinare i singoli stati direttamente dall’url. La navigazione viene gestita essenzialmente a client-side (dalla SPA, per intenderci) ma può anche essere gestita parzialmente dal server, per facilitare il processo di “rehydrating” (ripristino) dello stato richiesto.

fonte: http:// msdn.microsoft.com/en-us/magazine/dn463786.aspx Pro Le SPA sono quel tipo di applicazioni che assomigliano in tutto e per tutto ad applicazioni desktop tradizionali ma che sono realizzate per il web. Alcuni esempi: un gestionale interno di un’azienda, un configuratore, un CMS, un’applicazione che gestisca una serie di entità dietro autenticazione. Una volta scaricate sul client (il browser solitamente), queste comunicano via HTTP/AJAX/WebSocket con un formato standard (JSON) con il server, la cui implementazione né è completamente indipendente. Le SPA sono quindi stateful e agnostiche dal backend che fornisce le API: questo consente di sostituire in qualsivoglia momento il server. Essendo applicazioni indipendenti, possono essere gestite come progetti separati, permettendo una migliore manutenzione agli sviluppatori frontend. Un’altra qualità delle SPA è che hanno un loro sistema di routing interno, così come un template engine per generare l’HTML. Infine, possono essere usate in differenti campi, come ad esempio per la creazione di applicazioni ibride caricate su dispositivi mobili. Contro Di contro, non è consigliato usare le SPA per realizzare siti web che necessitano di SEO. Essendo il codice HTML renderizzato a client-side, i crawler dei motori di ricerca non riescono a interpretare e indicizzare l’applicazione (poco male se queste richiedono autenticazione). Un’altra nota dolente è il tempo di rendering iniziale: quando si chiede al server di scaricare il client a una qualsiasi rotta, questo dovrà seguire sempre lo stesso iter, ossia caricamento del DOM, caricamento del framework JS, caricamento dell’applicazione e infine ripristino dello stato richiesto (rehydrating). Framework Ci sono diversi framework Javascript che permettono di realizzare SPA. AngularJS, il noto framework di Google, ha già dimostrato una straordinaria abilità nel soddisfare i requisiti richiesti dalle SPA. Anche Ember ha dato un forte contributo negli anni, così come ExtJS di casa Sencha con il suo ecosistema di widget. Inoltre, nuovi framework sono nati negli ultimi anni, come Vue.js e Aurelia. ISOMORPHIC/UNIVERSAL WEB APPLICATIONS Le applicazioni Universal (un tempo “isomorfe” o Isomorphic Web Applications) hanno la particolarità di condividere lo stesso codice tra il client e il server, replicando le funzionalità di rendering dell’HTML su entrambi i fronti. Questo genere di applicazioni hanno le stesse funzionalità di una SPA sul client ma, chiamando direttamente il server, possono essere renderizzate come un tradizionale sito web scritto in PHP, con la particolarità che, una volta renderizzate sul client, funzioneranno indipendentemente continuando la comunicazione via AJAX, comportandosi come vere SPA.

fonte: http:// nerds.airbnb.com/isomorphic-javascript-future-web-apps/ Pro Questo genere di applicazioni è utilissimo quando Javascript copre l’intero stack di sviluppo e si vuole utilizzare la medesima logica di rendering sia a client che a server side. Data la possibilità di renderizzare l’HTML lato server, le applicazioni universali rispondono ai requisiti per fare SEO, ovviando alla limitazione della SPA. Inoltre, l’isomorfismo può essere visto come una sorta di superset delle SPA, essendo il client una potenziale applicazione a pagina singola: una volta che viene scaricato dal server, questo può renderizzare l’HTML per conto suo così come per la gestione del routing. Contro A differenza delle SPA, i tempi di sviluppo iniziale risultano più lunghi, dovendo generalizzare e astrarre i componenti e i moduli in modo che possano essere sfruttati comodamente dal server e dal client. Il suo punto forte è anche il suo punto debole: dovendo avere l’intero stack Javascript, il server non può essere scritto con un linguaggio differente (come PHP, Ruby, Python, …). Framework Uno dei primi framework a consolidare le applicazioni isomorfe/universali è stato Meteor, a cui hanno fatto seguito Derby, Ezel e l’ormai conosciutissimo di casa Facebook, ReactJS con JSX. Una lista dettagliata dei framework isomorfi può essere reperita a questo link: http://isomorphic.net/libraries HYBRID WEB APPLICATIONS Per applicazioni web ibride si intendono quelle applicazioni che possono essere installate come applicazioni native su un dispositivo mobile e vivono all’interno di una WebView, strato che viene configurato ad hoc da progetti come Cordova e PhoneGap. La particolarità di queste applicazioni è che possono interagire direttamente col dispositivo: possono accedere al file system, così come alla fotocamera, al GPS, alla rubrica e via dicendo.

fonte: http:// enterprisewebbook.com/ch13_hybrid.html Pro Quando si vogliono sfruttare appieno le funzionalità del dispositivo e dei componenti interni, allora le applicazioni ibride sono la soluzione ideale. La combinazione che favorisce questo genere di applicazioni sono le SPA e i progetti come Cordova e PhoneGap: una volta realizzata l’applicazione, si crea ciò che viene definito “build”, ossia un pacchetto che viene installato nativamente sul dispositivo, proprio come un’applicazione scaricata dallo store (pensate al relativo .ipa e .apk per i sistemi iOS e Android). Le piattaforme supportate sono differenti e ogni progetto mette a disposizione una lista di compatibilità. Contro Un primo difetto delle applicazioni ibride è che non sempre i plugin supportano appieno tutti i dispositivi principali e questo può risultare scomodo in fase di sviluppo. Un altro è che i plugin sono scritti col linguaggio nativo del sistema, quindi Swift/ObjectiveC per iOS, piuttosto che Java per Android e C# per Windows Phone: questo comporta avere competenze in differenti linguaggi e ambienti. Infine, le applicazioni ibride vengono eseguite in una WebView e questo strato è costoso in termini di performance, soprattutto quando si devono realizzare applicazioni che reagiscano immediatamente agli input dell’utente. Framework Anche in questo caso, per realizzare un’applicazione ibrida sono necessari due componenti: una SPA e uno strumento che permetta la pacchettizzazione. Cordova è sicuramente la soluzione più in voga che mette a disposizione, assieme a PhoneGap, una serie di plugin e un supporto molto forte per i vari dispositivi. A tal proposito, ngCordova è una libreria creata appositamente per Angular, così come Ionic Native come controparte per ES6 e TypeScript. NATIVE WEB APPLICATIONS Come le applicazioni web ibride, le Native Web Applications si comportano come applicazioni native per dispositivi mobili, con la possibilità di accedere ai componenti interni del dispositivo. La differenza sostanziale è che, invece di passare attraverso uno strato intermedio (Cordova/PhoneGap), queste parlano direttamente con le API del sistema operativo, risultando nettamente più performanti. Soluzioni di questo tipo sono NativeScript e React-Native.

fonte: https:// www. infoq.com/news/2015/03/nativescript Pro Quando si vogliono raggiungere altissime prestazioni, la soluzione nativa è sempre la scelta migliore. Così come quando un’applicazione è mirata solamente ai dispositivi mobili ma si vuol mantenere la possibilità di portarla comodamente su altri sistemi proprio come avviene con le ordinarie applicazioni web. Così come per le applicazioni ibride, le Native Web Applications necessitano di una SPA, garantendo così tutta la comodità nello sviluppo. Infine, alcuni progetti come NativeScript, permettono di interfacciarsi con le API del sistema operativo (iOS, Android, Windows Phone) direttamente in Javascript, senza dover conoscere ulteriori linguaggi di programmazione. Contro Sono mirate sostanzialmente per lo sviluppo mobile e la stilizzazione lato CSS è molto più ridotta rispetto a una tradizionale web application (facendo riferimento alle view native). Essendo abbastanza fresche come tipologia di applicazione, non hanno un così ampio supporto come le applicazioni ibride, perciò talvolta può essere difficile trovare risorse come plugins e addons che soddisfino le proprie necessità. Framework React-Native è la soluzione di casa Facebook che permette di realizzare applicazioni native per iOS e Android, fortemente basata sulla libreria React della medesima casa. NativeScript, più recente rispetto alla soluzione precedente, è stato introdotto da Telerik e supporta i tre sistemi maggiormente usati: iOS, Android e Windows Phone. PROGRESSIVE WEB APPLICATIONS Formulate nel 2015, le Progressive Web Applications vengono consolidate tra il 2016 e il 2017. Consistono in SPA o anche applicazioni isomorfe/universali che possono essere installate su dispositivi mobili senza passare per gli store. La differenza tra queste e quelle ibride e native è che rimangono applicazioni web (quindi non c’è integrazione con i componenti interni del dispositivo) ma possono essere aggiunte alla “home screen” e figurare come vere e proprie applicazioni di sistema, nonostante non lo siano. Queste applicazioni utilizzano i Service Workers per poter funzionare offline e un uso massiccio delle feature di HTML5.

fonte: https:// developers.google.com/web/updates/2015/11/app-shell Pro Evitare la registrazione delle applicazioni presso gli store è sicuramente un plus per gli sviluppatori, sia per quanto riguarda i tempi che i costi; lo stesso vale per gli utenti finali che non devono per forza scaricare l’applicazione ma possono semplicemente aggiungerla allo screen. Poter usare un’applicazione web come un’applicazione nativa è vantaggioso perché non necessita il setup dell’ambiente su cui si vuole distribuire il progetto e, all’interno del sistema operativo, figura come un’app indipendente e svincolata dal browser. Infine non necessitano di particolari librerie, se non un forte uso di HTML5. Contro Sono nuovissime, talmente nuove che alcune funzionalità sono supportate soltanto dalle ultimissime release dei browser mobile. Tutto ciò che ne consegue è che non risultano pronte per la produzione ma sono da considerarsi una tecnologia che acquisirà sicurezza e stabilità soltanto in futuro. Framework HTML5. Il resto possono essere librerie che gestiscano meglio le feature messe a disposizione, come per i ServiceWorker e i WebWorker. RIEPILOGO Non esiste una tipologia di applicazione migliore delle altre, bensì un insieme di soluzioni che rispondono a determinate esigenze. Tal volta alcune possono essere più adeguate di altre ma dipende sempre dal tipo di contesto e dai requisiti. Sicuramente un fattore comune sono le SPA che continueranno ad essere sul panorama delle applicazioni web ancora per diverso tempo. Come linea generale, potete tenere a mente la seguente: - applicazione web tradizionale: SPA - sito web che necessita di SEO con qualità di applicazione web: Isomorphic/Universal Web Applications - applicazione mobile: Hybrid Web Application - applicazione mobile con forti requisiti di performance: Native Web Applications - applicazione web che possa lavorare offline: Progressive Web Applications Questo è solo un consiglio; l’importante è una buona analisi dei requisiti, seguita dalla scelta più appropriata.