Ultimamente si è parlato molto delle app web progressive. Si tratta ancora di un modello relativamente nuovo, ma i suoi principi possono migliorare allo stesso modo le app create con JS, React, Polymer, Angular o qualsiasi altro framework. In questo post, riassumerò alcune opzioni e le app di riferimento per iniziare a utilizzare oggi la tua app web progressiva.
Che cos'è un'app web progressiva?
È importante ricordare che le app web progressive funzionano ovunque, ma sono ottimizzate nei browser moderni. Il miglioramento progressivo è una spina dorsale del modello.
Aaron Gustafson ha paragonato il miglioramento progressivo a un M&M con arachidi. L'arachide è il tuo contenuto, il rivestimento di cioccolato è il tuo livello di presentazione e il tuo JavaScript è il guscio duro. Il colore di questo livello e l'esperienza possono variare in base alle funzionalità del browser che lo utilizza.
Pensa alla shell come al luogo in cui possono essere ospitate molte funzionalità delle app web progressive. Sono esperienze che combinano il meglio del web e il meglio delle app. Sono utili per gli utenti fin dalla prima visita in una scheda del browser; non è richiesta alcuna installazione.
Man mano che l'utente instaura una relazione con queste app tramite l'uso ripetuto, le app rendono ancora più dolce la caramella: caricamento molto rapido su connessioni di rete lente (grazie ai service worker), invio di notifiche push pertinenti e un'icona di prima classe nella schermata Home dell'utente che può caricarle come esperienze di app a schermo intero. Possono anche usufruire di banner per l'installazione di app web intelligenti.
Le app web progressive sono
- Progressivi: funzionano per tutti gli utenti, indipendentemente dal browser scelto, perché sono creati con il potenziamento progressivo come tenant di base.
- Adattabile: si adatta a qualsiasi fattore di forma, computer, dispositivo mobile, tablet o a qualsiasi altro fattore.
- Indipendente dalla connettività - Funzionalità migliorata con service worker per lavorare offline o su reti di bassa qualità.
- Simile all'app: utilizza il modello della shell dell'app per fornire navigazioni e interazioni in stile app.
- Nuovo: sempre aggiornato grazie al processo di aggiornamento del service worker.
- Sicura: pubblicata tramite TLS per impedire lo snooping e garantire che i contenuti non siano stati manomessi.
- Rilevabili - Sono identificabili come "applicazioni" grazie ai file manifest W3C e all'ambito di registrazione dei service worker, che consentono ai motori di ricerca di trovarli.
- Possibilità di ricoinvolgimento: semplifica il ricoinvolgimento tramite funzionalità come le notifiche push.
- Installabile: consente agli utenti di "conservare" le app che ritengono più utili nella schermata Home senza dover utilizzare un app store.
- Collegabile: condividi facilmente tramite URL e non richiede un'installazione complessa.
Inoltre, le app web progressive non sono un'esclusiva di Chrome per Android. Di seguito possiamo vedere l'app web progressiva Pokedex in esecuzione in Firefox per Android (beta) con le funzionalità iniziali di Aggiungi alla schermata Home e della memorizzazione nella cache dei worker di servizio che funzionano perfettamente.
Uno degli aspetti positivi della natura "progressiva" di questo modello è che le funzionalità possono essere sbloccate gradualmente man mano che i fornitori di browser offrono un supporto migliore. Le app web progressive come Pokedex sono ovviamente molto efficaci anche in Opera su Android, con alcune notevoli differenze nell'implementazione:
Per approfondire le app web progressive, leggi il post del blog originale di Alex Russell che le presenta. Paul Kinlan ha anche creato un utile tag Stack Overflow per le app web progressive che vale la pena consultare.
Princìpi
Manifest dell'app web
Il file manifest consente alla tua app web di avere una presenza più simile a quella nativa nella schermata Home dell'utente. Consente di avviare l'app in modalità a schermo intero (senza barra degli URL), offre il controllo sull'orientamento dello schermo e nelle versioni recenti di Chrome su Android supporta la definizione di una schermata iniziale e di un colore del tema per la barra degli indirizzi. Viene utilizzato anche per definire un insieme di icone per dimensioni e densità utilizzate per la schermata iniziale e l'icona della schermata iniziale sopra menzionate.
Un file manifest di esempio è disponibile nel Web Starter Kit e nei Samples di Google Chrome. Bruce Lawson ha scritto un generatore di manifest e Mounir Lamouri ha anche scritto un pratico strumento di convalida del manifest web che vale la pena provare.
Nei miei progetti personali, mi affido a realfavicongenerator per generare icone con le dimensioni corrette sia per il manifest dell'app web sia per l'utilizzo su iOS, computer e così via. Il modulo Node favicons è in grado di generare un output simile anche durante il processo di compilazione.
I browser basati su Chromium (Chrome, Opera e così via) supportano i manifest delle app web oggi, con Firefox che sviluppa attivamente il supporto e Edge che li elenca come in fase di considerazione. WebKit/Safari non ha ancora pubblicato indicatori pubblici sulle loro intenzioni di implementare la funzione.
Per ulteriori dettagli, leggi App web installabili con il manifest dell'app web in Chrome per Android su Web Fundamentals.
Banner "Aggiungi a schermata Home"
Chrome su Android supporta l'aggiunta del tuo sito alla schermata Home da un po' di tempo, ma le versioni recenti supportano anche la proposta proattiva di siti da aggiungere utilizzando i banner di installazione di app web nativi.
Affinché le richieste di installazione mostrino l'app, devi:
- Avere un manifest dell'app web valido
- Essere pubblicata tramite HTTPS (visita letsencrypt per un certificato senza costi)
- Avere un service worker valido registrato
- Essere visitato due volte, con almeno 5 minuti tra una visita e l'altra
Sono disponibili diversi esempi di banner di installazione di app, che vanno dai banner di base a casi d'uso più complessi come la visualizzazione di applicazioni correlate.
Service worker per la memorizzazione nella cache offline
Un service worker è uno script che viene eseguito in background, separatamente dalla pagina web. Risponde agli eventi, incluse le richieste di rete effettuate dalle pagine che pubblica. Un service worker ha una durata intenzionalmente breve.
Si attiva quando riceve un evento ed esegue solo il tempo necessario per elaborarlo. Il servizio worker ti consente di utilizzare l'API Cache per memorizzare nella cache le risorse e può essere utilizzato per offrire agli utenti un'esperienza offline.
I worker di servizio sono molto efficaci per la memorizzazione nella cache offline, ma offrono anche miglioramenti significativi delle prestazioni sotto forma di caricamento istantaneo per le visite ripetute al tuo sito o alla tua app web. Puoi memorizzare nella cache la shell dell'applicazione in modo che funzioni offline e compilarne i contenuti utilizzando JavaScript.
Un insieme completo di esempi di service worker è disponibile negli esempi di Google Chrome. La cookbook offline di Jake Archibald è un must read e consiglio vivamente di provare la procedura dettagliata di Paul Kinlan per creare la tua prima app web offline se non hai dimestichezza con i worker di servizio.
Il nostro team gestisce anche una serie di utilità di assistenza e strumenti di compilazione per i worker di servizio che riteniamo utili per ridurre il sovraccarico durante la configurazione dei worker di servizio. Sono elencate nella pagina Librerie Service Worker. I due principali sono:
- sw-precache: uno strumento di compilazione che genera uno script di service worker utile per eseguire il precaching della shell dell'app web
- sw-toolbox: una libreria che fornisce la memorizzazione nella cache di runtime per le risorse utilizzate di rado
Jeff Posnick ha scritto un breve introduzione a sw-precache chiamata Offline-first, fast, con il modulo sw-precache e un codelab sullo stesso strumento che potresti trovare utile.
Chrome, Opera e Firefox hanno implementato il supporto per i worker di servizio, mentre Edge ha indicatori pubblici positivi sull'interesse per la funzionalità. Safari ha brevemente menzionato il proprio interesse tramite il piano quinquennale proposto da un ingegnere.
Notifiche push per il ricoinvolgimento
In pratica, puoi creare app web con cui gli utenti possono interagire al di fuori di una scheda. Il browser può essere chiuso e non è nemmeno necessario che l'utente utilizzi attivamente la tua app web per interagire con la tua esperienza. La funzionalità richiede sia il service worker sia un file manifest dell'app web, basandosi su alcune delle funzionalità riassunte in precedenza.
L'API Push è implementata in Chrome, in fase di sviluppo in Firefox e in fase di valutazione in Edge. Al momento non sono disponibili indicatori pubblici da parte di Safari sulla sua intenzione di implementare questa funzionalità.
Notifiche push sul web aperto è un'introduzione completa alla configurazione delle notifiche push di Matt Gaunt ed è disponibile anche un codelab sulle notifiche push su Web Fundamentals.
Se preferisci i video, Michael van Ouwerkerk del team di Chrome ha anche una presentazione di 6 minuti su Push.
Applicazione di funzionalità avanzate
Ricorda che la tua esperienza utente può avere diversi livelli di dolcezza a seconda del browser utilizzato per visualizzare la tua app web. Sei tu a controllare la copertura del caramello duro.
In questo modo, è possibile applicare alla tua app web progressive anche funzionalità aggiuntive che verranno implementate nella piattaforma web, come la sincronizzazione in background (per la sincronizzazione dei dati con un server anche quando l'app web è chiusa) e il Bluetooth web (per comunicare con i dispositivi Bluetooth dalla tua app web).
La sincronizzazione in background una tantum è stata attivata in Chrome e Jake Archibald ha realizzato un video della sua app Wikipedia offline e un articolo che la mostrano in azione. François Beaufort ha anche una serie di esempi di Bluetooth web disponibili se si è interessati a provare l'API.
Supporta i framework
Nulla ti impedisce di applicare uno qualsiasi dei principi sopra elencati a un'applicazione o a un framework esistente con cui stai creando. Alcuni altri principi da tenere a mente durante la creazione dell'app web progressiva sono il modello di rendimento incentrato sull'utente RAIL e le animazioni basate su FLIP.
Mi auguro che nel corso del 2016 vedremo un numero crescente di boilerplate e progetti di seed che integreranno in modo organico il supporto delle Progressive Web App come funzionalità di base. Fino ad allora, l'ostacolo per l'aggiunta di queste funzionalità alle tue app non è molto elevato e vale la pena fare impegno.
Architettura
Esistono diversi livelli di "tutto compreso" nel modello di app web progressiva, ma un approccio comune è la loro progettazione sulla base di una shell dell'applicazione. Non si tratta di un requisito obbligatorio, ma offre diversi vantaggi.
L'architettura dell'involucro dell'applicazione incoraggia la memorizzazione nella cache dell'involucro dell'applicazione (l'interfaccia utente) in modo che funzioni offline e completi i contenuti utilizzando JavaScript. Nelle visite ripetute, questo consente di ottenere pixel significativi sullo schermo molto velocemente senza la rete, anche se alla fine i tuoi contenuti provengono da lì. Ciò comporta un notevole aumento delle prestazioni.
Di recente Jeremy Keith ha commentato che in questo tipo di modello il rendering lato server non dovrebbe essere considerato un piano di riserva, ma il rendering lato client dovrebbe essere considerato un miglioramento. Questo è un feedback giusto.
Nel modello di shell dell'applicazione, il rendering lato server deve essere utilizzato il più possibile e il rendering progressivo lato client deve essere utilizzato come miglioramento nello stesso modo in cui "miglioriamo" l'esperienza quando il servizio worker è supportato. Esistono molti modi per affrontare questo problema.
Ti consiglio di leggere il nostro articolo sull'architettura e di valutare in che modo principi simili potrebbero essere applicati al meglio alla tua applicazione e al tuo stack.
Boilerplate per iniziare
Shell dell'applicazione
Il repository app-shell contiene un'implementazione quasi completa dell'architettura Application Shell. Ha un backend scritto in Express.js e un front-end scritto in ES2015.
Dato che copre sia le parti client sia quelle server del modello e che ci sono molte cose da fare, ci vuole un po' di tempo per acquisire familiarità con la base di codice. È il nostro punto di partenza attuale più completo per le app web progressive. La documentazione sarà il nostro prossimo obiettivo per questo progetto.
Starter kit per polimeri
Il punto di partenza ufficiale per le app web Polymer supporta le seguenti funzionalità delle app web progressive:
- Manifest dell'applicazione web
- Schermata iniziale di Chrome per Android
- Memorizzazione nella cache offline dei service worker con gli elementi SW Platinum
- Notifiche push (configurazione manuale richiesta) con gli elementi Push Platinum
Nella versione corrente di PSK non è supportato alcuni dei pattern di prestazioni più avanzati (ad es.il modello di shell dell'applicazione, il caricamento asincrono) che si trovano in alcune app web progressive in Polymer.
Il nostro obiettivo è provare a integrare questi pattern in PSK nel 2016, ma i primi esperimenti in merito sono disponibili nell'app Polymer Zuperkulblog di Rob Dodson e nell'eccellente talk Polymer Perf Patterns di Eric Bidelman.
Starter kit per il web
Il nostro punto di partenza per i nuovi progetti "vanilla" include le seguenti funzionalità delle app web progressive:
- Manifest dell'applicazione web
- Schermata iniziale di Chrome per Android
- Pre-memorizzazione nella cache dei service worker grazie a sw-precache
Se preferisci lavorare con Vanilla JS/ES2015 e non riesci a utilizzare Polymer, Web Starter Kit può rivelarsi utile come punto di riferimento da cui puoi riutilizzare o sottrarre snippet di codice.
App web progressive con e senza framework
I membri della community hanno già creato diverse app web progressive open source, sia con che senza librerie e framework JS. Se cerchi ispirazione, i repo riportati di seguito potrebbero esserti utili come riferimento. Sono anche app davvero ottime.
Vanilla JavaScript
- Memo vocali di Paul Lewis è realizzato utilizzando un'architettura simile a
app-shell(report) - Wikipedia offline di Jake Archibald (video)
- Air Horner di Paul Kinlan
- Accordatore per chitarra di Paul Lewis (articolo)
Polymer
- Zuperkulblog di Rob Dodson (slide)
React
- iFixit di Jeff Posnick: utilizza
sw-precacheper la memorizzazione nella cache della shell dell'applicazione (slide)
Virtual-DOM
- Pokedex di Nolan Lawson: un'eccellente app web progressiva che applica un approccio "fai tutto in un web worker" per facilitare il rendering progressivo. (report)
Angular.js
- Timey.in di Kenneth Auchenberg: utilizza anche
sw-precacheper il pre-caching delle risorse
Note finali
Come accennato, le app web progressive sono ancora agli inizi, ma è un momento entusiasmante per sperimentare le metodologie alla base e scoprire quanto bene possono essere applicate alle tue app web.
Paul Kinlan sta attualmente pianificando le indicazioni di Web Fundamentals sulle app web progressive. Se hai suggerimenti sulle aree che vorresti fossero trattate, non esitare a commentare il thread.
Per approfondire
- App web progressive: sfuggire alle schede senza perdere la nostra anima
- Perché le app web progressive sono il futuro dello sviluppo web
- App web progressive: pronte per il lancio
- Creare un'app progressiva con ServiceWorker
- Le app web progressive sono il futuro
- App web progressiva: un nuovo modo di utilizzare i dispositivi mobili
- Presentazione di Pokedex.org: un'app web progressiva per i fan dei Pokémon
- Riepilogo del Chrome Developer Summit: app web progressive