Ultimamente si è parlato molto di app web progressive. Sono ancora un modello relativamente nuovo, ma i loro principi possono migliorare allo stesso modo le app create con vanilla JS, React, Polymer, Angular o qualsiasi altro framework. In questo post riassumerò alcune opzioni e app di riferimento per iniziare a utilizzare la tua app web progressiva oggi stesso.
Che cos'è un'app web progressiva?
È importante ricordare che le app web progressive funzionano ovunque, ma sono potenziate nei browser moderni. Il potenziamento progressivo è un elemento fondamentale del modello.
Aaron Gustafson ha paragonato il potenziamento progressivo a un M&M's con arachidi. La nocciolina sono i tuoi contenuti, il rivestimento di cioccolato è il livello di presentazione e il JavaScript è il guscio di caramella dura. Questo livello può variare di colore e l'esperienza può variare a seconda delle funzionalità del browser che lo utilizza.
Pensa al guscio di caramella come al luogo in cui possono risiedere 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, senza bisogno di installazione.
Man mano che l'utente instaura un rapporto con queste app attraverso un utilizzo ripetuto, il guscio di caramella diventa ancora più dolce: si caricano molto velocemente su connessioni di rete lente (grazie al service worker), inviano notifiche push pertinenti e hanno un'icona di prima classe nella schermata Home dell'utente che può caricarle come esperienze con l'app a schermo intero. Possono anche usufruire dei banner per l'installazione di app web intelligenti.
Le app web progressive sono
- Progressive: funzionano per ogni utente, indipendentemente dal browser scelto, perché sono create con il potenziamento progressivo come principio fondamentale.
- Adattabilità: si adattano a qualsiasi fattore di forma, computer, dispositivo mobile, tablet o qualsiasi altro dispositivo futuro.
- Indipendenza dalla connettività: migliorate con i service worker per funzionare offline o su reti di bassa qualità.
- Simile a un'app: utilizza il modello di shell dell'app per fornire navigazioni e interazioni in stile app.
- Aggiornate: sempre aggiornate grazie al processo di aggiornamento del service worker.
- Sicuro: pubblicato tramite TLS per impedire lo snooping e garantire che i contenuti non siano stati manomessi.
- Rilevabili: sono identificabili come "applicazioni" grazie ai manifest W3C e all'ambito di registrazione dei service worker che consentono ai motori di ricerca di trovarle.
- Ricoinvolgimento: semplifica il ricoinvolgimento tramite funzionalità come le notifiche push.
- Installabile: consenti agli utenti di "conservare" le app che ritengono più utili sulla schermata Home senza dover ricorrere a uno store.
- Collegabile: si condivide facilmente tramite URL e non richiede un'installazione complessa.
Inoltre, le app web progressive non sono esclusive di Chrome per Android. Di seguito possiamo vedere l'app web progressiva Pokedex in esecuzione su Firefox per Android (beta) con le prime funzionalità di memorizzazione nella cache di service worker e Aggiungi a schermata Home 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. Naturalmente, anche le app web progressive come Pokedex funzionano benissimo in Opera su Android, con alcune differenze di implementazione degne di nota:
Per approfondire l'argomento delle app web progressive, leggi il blog post originale di Alex Russell che le introduce. Paul Kinlan ha anche avviato un tag Stack Overflow molto utile per le app web progressive che vale la pena consultare.
Principi
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 la barra degli URL), fornisce 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 in base alle dimensioni e alla densità utilizzate per la schermata iniziale e l'icona della schermata Home sopra menzionate.
Un file manifest di esempio è disponibile in Web Starter Kit e negli esempi di Google Chrome. Bruce Lawson ha scritto un generatore di manifest e Mounir Lamouri ha scritto anche un pratico strumento di convalida dei manifest web che vale la pena consultare.
Nei miei progetti personali, mi affido a realfavicongenerator per generare le icone di dimensioni corrette sia per il file manifest dell'app web sia per l'utilizzo su iOS, computer e così via. Anche il modulo Node favicons è in grado di ottenere un output simile nell'ambito del processo di build.
I browser basati su Chromium (Chrome, Opera e così via) supportano i manifest delle app web, mentre Firefox sta sviluppando attivamente il supporto ed Edge li elenca come in fase di valutazione. WebKit/Safari non hanno ancora pubblicato indicatori pubblici sulle loro intenzioni di implementare la funzionalità.
Per maggiori 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 già da un po' di tempo, ma le versioni recenti supportano anche il suggerimento proattivo di aggiungere siti utilizzando i banner di installazione di app web nativi.
Affinché vengano visualizzate le richieste di installazione dell'app, l'app deve:
- Avere un manifest dell'app web valido
- Essere pubblicata tramite HTTPS (consulta letsencrypt per un certificato senza costi).
- Avere un service worker valido registrato
- Essere visitato due volte, con almeno 5 minuti di intervallo tra le visite
Sono disponibili diversi esempi di banner per l'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 gestisce. Un service worker ha una durata intenzionalmente breve.
Si attiva quando riceve un evento e viene eseguita solo per il tempo necessario a elaborarlo. Il service 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 service worker sono potenti per la memorizzazione nella cache offline, ma offrono anche significativi vantaggi in termini di prestazioni, come il 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 compilare i relativi contenuti utilizzando JavaScript.
Un insieme completo di esempi di service worker è disponibile negli esempi di Google Chrome. Il cookbook offline di Jake Archibald è una lettura obbligatoria e consiglio vivamente di provare la procedura dettagliata di Paul Kinlan per la tua prima app web offline se non hai dimestichezza con i service worker.
Il nostro team gestisce anche una serie di utilità di supporto per i service worker e strumenti di build che riteniamo utili per ridurre l'overhead nella configurazione dei service worker. Sono elencate in Librerie di service worker. I due principali sono:
- sw-precache: uno strumento di build-time che genera uno script service worker utile per pre-memorizzare nella cache la 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 una breve guida su sw-precache intitolata Offline-first, fast, with the sw-precache module e un codelab sullo stesso strumento che potrebbe esserti utile.
Chrome, Opera e Firefox hanno tutti implementato il supporto per i service worker, mentre Edge ha mostrato segnali pubblici positivi di interesse per la funzionalità. Safari ha brevemente menzionato l'interesse per questa funzionalità 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 gli utenti utilizzino attivamente la tua app web per interagire con la tua esperienza. La funzionalità richiede sia un service worker sia un manifest dell'app web, basandosi su alcune delle funzionalità riepilogate in precedenza.
L'API Push è implementata in Chrome, in fase di sviluppo in Firefox e in fase di valutazione in Edge. Al momento non ci sono segnali pubblici da parte di Safari sulla sua intenzione di implementare questa funzionalità.
Push Notifications on the Open Web è un'introduzione completa alla configurazione delle notifiche push di Matt Gaunt. Inoltre, un codelab sulle notifiche push è disponibile anche su Web Fundamentals.
Michael van Ouwerkerk del team di Chrome ha anche un'introduzione di 6 minuti alle notifiche push se preferisci i video.
Integrazione di funzionalità avanzate
Ricorda che l'esperienza utente può avere diversi livelli di dolcezza a seconda del browser utilizzato per visualizzare l'app web. Sei tu a controllare il guscio di caramella dura.
Anche le funzionalità aggiuntive in arrivo sulla piattaforma web, come la sincronizzazione in background (per la sincronizzazione dei dati con un server anche quando l'app web è chiusa) e Web Bluetooth (per comunicare con i dispositivi Bluetooth dall'app web), possono essere integrate nella tua app web progressiva in questo modo.
La sincronizzazione in background one-shot è stata attivata in Chrome e Jake Archibald ha un video della sua app Wikipedia offline e un articolo che ne dimostrano il funzionamento. François Beaufort ha anche una serie di esempi di Web Bluetooth disponibili se ti interessa provare l'API.
Compatibilità con i framework
Non c'è nulla che ti impedisca di applicare uno dei principi sopra indicati a un'applicazione o a un framework esistente con cui stai creando. Altri principi da tenere a mente durante la creazione della tua app web progressiva sono il modello di prestazioni incentrato sull'utente RAIL e le animazioni basate su FLIP.
Spero che nel corso del 2016 vedremo un numero crescente di boilerplate e progetti di base che integrano in modo organico il supporto per le app web progressive come funzionalità principale. Fino ad allora, la barriera per aggiungere queste funzionalità alle tue app non è molto alta e, secondo me, vale la pena fare lo sforzo.
Architettura
Esistono diversi livelli di "all-in" nel modello di app web progressiva, ma un approccio comune è quello di progettarle attorno a una shell dell'applicazione. Non si tratta di un requisito obbligatorio, ma offre diversi vantaggi.
L'architettura della shell dell'applicazione incoraggia la memorizzazione nella cache della shell dell'applicazione (l'interfaccia utente) in modo che funzioni offline e compili i suoi contenuti utilizzando JavaScript. In caso di visite ripetute, questo consente di visualizzare pixel significativi sullo schermo molto rapidamente senza la rete, anche se i contenuti provengono da lì. Ciò comporta notevoli miglioramenti delle prestazioni.
Jeremy Keith ha recentemente commentato che in questo tipo di modello forse il rendering lato server non dovrebbe essere visto come un fallback, ma il rendering lato client dovrebbe essere considerato un miglioramento. Questo è un feedback corretto.
Nel modello 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 service worker è supportato. Esistono molti modi per affrontare questo problema.
Il mio consiglio è di leggere il nostro articolo sull'architettura e valutare come applicare al meglio principi simili alla tua applicazione e al tuo stack.
Boilerplate per iniziare
Shell dell'applicazione
Il repository app-shell contiene un'implementazione quasi completa dell'architettura della shell dell'applicazione. Ha un backend scritto in Express.js e un frontend scritto in ES2015.
Poiché copre sia le parti lato client che quelle lato server del modello e ci sono molte cose da fare, ci vorrà un po' di tempo per acquisire familiarità con il codebase. Altrimenti, al momento è il nostro punto di partenza più completo per le app web progressive. Documenti sarà il nostro prossimo obiettivo per questo progetto.
Starter kit Polymer
Il punto di partenza ufficiale per le app web Polymer supporta le seguenti funzionalità delle app web progressive:
- Manifesto dell'applicazione web
- Schermata iniziale di Chrome per Android
- Memorizzazione nella cache offline del service worker con gli elementi Platinum SW
- Notifiche push (è richiesta la configurazione manuale) con gli elementi Platinum Push
La versione attuale di PSK non supporta 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 Polymer progressive.
Il nostro obiettivo è provare a integrare questi pattern in PSK nel 2016, ma i primi esperimenti in questo senso sono disponibili nell'app Polymer Zuperkulblog di Rob Dodson e nell'eccellente talk Polymer Perf Patterns di Eric Bidelman.
Web Starter Kit
Il nostro punto di partenza per i nuovi progetti vanilla include le seguenti funzionalità delle app web progressive:
- Manifesto dell'applicazione web
- Schermata iniziale di Chrome per Android
- Pre-memorizzazione nella cache del service worker grazie a sw-precache
Se preferisci lavorare con vanilla JS/ES2015 e non puoi utilizzare Polymer, Web Starter Kit può rivelarsi utile come punto di riferimento che puoi riutilizzare o da cui puoi copiare snippet di codice.
App web progressive con e senza framework
I membri della community hanno già creato una serie di app web progressive open source con e senza librerie e framework JS. Se cerchi ispirazione, i repository riportati di seguito potrebbero essere utili come riferimento. Inoltre, sono app davvero fantastiche.
Vanilla JavaScript
- Memo vocali di Paul Lewis è stato creato utilizzando un'architettura simile a
app-shell(articolo) - Offline Wikipedia di Jake Archibald (video)
- Air Horner di Paul Kinlan
- Guitar Tuner 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. (write-up)
Angular.js
- Timey.in di Kenneth Auchenberg: utilizza anche
sw-precacheper il pre-memorizzazione nella cache delle risorse
Note di chiusura
Come accennato, le app web progressive sono ancora agli inizi, ma è un momento entusiasmante per sperimentare le metodologie alla base e vedere quanto 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 vedere trattate, non esitare a commentare nel thread.
Per approfondire
- App web progressive: uscire dalle schede senza perdere l'anima
- Why Progressive Web Apps Are The Future Of Web Development
- App web progressive: pronte per il debutto
- Creazione di un'app web progressiva con ServiceWorker
- Le app web progressive sono il futuro
- App web progressiva: un nuovo modo di vivere l'esperienza mobile
- Introducing Pokedex.org: a progressive webapp for Pokémon fans
- Chrome Developer Summit Recap: Progressive Web Apps