Ultimamente si è parlato molto delle app web progressive. È ancora un modello relativamente nuovo, ma i suoi principi possono ugualmente migliorare le app create con vanilla JS, React, Polymer, Angular o qualsiasi altro framework. In questo post riassumerò alcune opzioni e alcune app di riferimento per iniziare a utilizzare oggi stesso la tua app web progressiva.
Che cos'è un'app web progressiva?
È importante ricordare che le app web progressive funzionano ovunque, ma sono potenziate nei browser moderni. Il miglioramento progressivo è una spina dorsale del modello.
Aaron Gustafson ha paragonato il miglioramento progressivo a un M&M "arachide". L'arachide è il tuo contenuto, il rivestimento di cioccolato è il tuo livello di presentazione e il tuo JavaScript è il guscio duro. 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 a dove possono trovarsi molte funzionalità delle app web progressive. Si tratta di 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 costruisce una relazione con queste app tramite un uso ripetuto, rende ancora più dolce la shell di zucchero, caricando molto velocemente in caso di connessioni di rete lente (grazie al service worker), inviando notifiche push pertinenti e con un'icona all'avanguardia nella schermata Home per caricarle come app a schermo intero. Possono inoltre usufruire dei banner di installazione di app web intelligenti.
Le app web progressive
- Progressivo: funzionano per tutti gli utenti, indipendentemente dalla scelta del browser, perché sono creati con un miglioramento progressivo come tenant principale.
- 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 a un'app: utilizza il modello shell dell'app per fornire navigazioni e interazioni in stile app.
- Nuovo: sempre aggiornato 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 file manifest W3C e all'ambito di registrazione dei service worker, che consentono ai motori di ricerca di trovarli.
- Ricoinvolgimento: semplifica il ricoinvolgimento tramite funzionalità come le notifiche push.
- Installabile: consente agli utenti di "conservare" le app che trovano più utili nella schermata Home senza la seccatura di uno store.
- Collegabile: condividi facilmente tramite URL e non richiede un'installazione complessa.
Inoltre, le app web progressive non sono specifiche di Chrome per Android. Di seguito possiamo vedere l'app web progressiva Pokedex che funziona in Firefox per Android (beta) e le funzionalità di aggiunta alla schermata Home e di memorizzazione nella cache dei service worker 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 con 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 introduce. Paul Kinlan ha anche creato un utile tag Stack Overflow per le app web progressive che vale la pena consultare.
Princìpi
File manifest dell'app web
Il file manifest consente alla tua app web di avere una presenza più nativa sulla schermata Home dell'utente. Consente di avviare l'app in modalità a schermo intero (senza che sia presente una barra dell'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 a dimensione e densità utilizzate per la schermata iniziale e l'icona della schermata Home sopra menzionate.
Puoi trovare un file manifest di esempio in Web Starter Kit e versioni successive negli esempi di Google Chrome. Bruce Lawson ha scritto un Manifest Generator e Mounir Lamouri ha anche scritto un utile strumento di convalida dei manifest web che vale la pena provare.
Nei miei progetti personali, mi affido a realfavicongenerator per generare le icone delle dimensioni corrette sia per il file manifest dell'app web sia per l'uso su iOS, computer e così via. Anche il modulo Nodo favicon è in grado di ottenere un output simile come parte del processo di compilazione.
Oggi, i browser basati su Chromium (Chrome, Opera ecc.) supportano l'app web si manifestano con Firefox in fase di sviluppo del supporto e Edge li elenca come in considerazione. WebKit/Safari non ha ancora pubblicato indicatori pubblici sulle loro intenzioni di implementare la funzione.
Per maggiori dettagli, leggi l'articolo App web installabili con il file manifest delle app web in Chrome per Android su Web Fundamentals.
Banner "Aggiungi a schermata Home"
Chrome su Android supporta già da un po' di tempo l'aggiunta dei siti alla schermata Home, ma le versioni recenti supportano anche il suggerimento proattivo di aggiungere i siti utilizzando banner di installazione di app web nativi.
Affinché le richieste di installazione mostrino l'app, devi:
- Avere un file manifest dell'app web valido
- Essere pubblicate tramite HTTPS (consulta letsencrypt per un certificato senza costi)
- Avere un service worker valido registrato
- Essere visitata due volte, con almeno 5 minuti di visita tra una visita e l'altra
Sono disponibili numerosi esempi di banner per l'installazione di app, che comprendono i banner di base e i 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, separato 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 e viene eseguito solo per il tempo necessario all'elaborazione. Il Service worker consente di utilizzare l'API Cache per memorizzare le risorse nella cache 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 vantaggi significativi in termini di prestazioni sotto forma di caricamento istantaneo per visite ripetute al tuo sito o alla tua app web. Puoi memorizzare nella cache la shell dell'applicazione in modo che funzioni offline e compili i relativi contenuti utilizzando JavaScript.
Su Google Chrome è disponibile una serie completa di esempi di worker di servizio. Il libro di ricette offline di Jake Archibald è assolutamente da leggere e ti consiglio caldamente di provare la procedura dettagliata della tua prima app web offline di Paul Kinlan se non hai mai utilizzato un service worker.
Il nostro team gestisce anche una serie di utilità helper per i service worker e crea strumenti che troviamo utili per ridurre i costi generali necessari per la configurazione dei service worker. Sono elencati nelle librerie dei service worker. I due principali sono:
- sw-precache: uno strumento di compilazione che genera uno script del service worker utile per prememorizzare nella cache la shell dell'app web
- sw-toolbox: una libreria che fornisce la memorizzazione nella cache di runtime per le risorse utilizzate raramente
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 service worker con Edge che riceve segnali pubblici positivi sull'interesse per la funzionalità. Safari ha brevemente menzionato l'interesse per il progetto tramite il piano quinquennale proposto da un ingegnere.
Notifiche push per ricoinvolgimento
Puoi creare app web con cui gli utenti possano interagire al di fuori di una scheda. Il browser può essere chiuso e non è necessario utilizzare 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 considerazione in Edge. Safari non ha ancora ricevuto indicatori pubblici sull'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.
Michael van Ouwerkerk del team di Chrome ha anche una presentazione di 6 minuti a Push se ti interessa soprattutto video.
Sovrapposizione delle 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 ad avere il controllo del guscio di dolcezza.
Ulteriori funzionalità presto disponibili sulla piattaforma web, come la sincronizzazione in background (per la sincronizzazione dei dati con un server anche quando l'app web è chiusa) e Bluetooth web (per comunicare con i dispositivi Bluetooth dalla tua 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 dell'app Wikipedia offline e un articolo che lo dimostra in azione. Francois Beaufort ha anche a disposizione una serie di esempi di Bluetooth sul web se si è interessati a provare quell'API.
Compatibilità con 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 che vale la pena tenere a mente durante la creazione della tua app web progressiva sono il modello di rendimento incentrato sull'utente RAIL e le animazioni basate su FLIP.
Spero che nel 2016 assisteremo a una crescita organica dei boilerplate e dei progetti di avviamento organico a supporto delle app web progressive come funzionalità principale. 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 difficile, 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 relativi 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ò porta a un aumento significativo del rendimento.
Di recente Jeremy Keith ha commentato che in questo tipo di modello forse il rendering lato server non dovrebbe essere visto come un'alternativa, ma il rendering lato client dovrebbe essere visto come un miglioramento. Questo è un feedback equo.
Nel modello della shell dell'applicazione, il rendering lato server deve essere usato il più possibile e il rendering progressivo lato client deve essere usato come miglioramento allo stesso modo in cui "miglioriamo" l'esperienza quando il service worker è supportato. Ci sono molti modi per affrontarla.
Ti consiglio di leggere il nostro riepilogo sull'architettura e di valutare come principi simili potrebbero essere applicati al meglio alle tue applicazioni 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 front-end scritto in ES2015.
Dato che copre le parti del modello sia lato client che lato server e le cose sono molte, ci vorrà un po' di tempo per familiarizzare con il codebase. È il nostro punto di partenza attuale più completo per le app web progressive. Il prossimo obiettivo di questo progetto sarà Documenti.
Starter kit in polimeri
Il punto di partenza ufficiale per le app web Polymer supporta le seguenti funzionalità delle app web progressive:
- File 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
La versione attuale di PSK non supporta alcuni dei pattern di prestazioni più avanzati (ad esempio il modello della shell dell'applicazione, il caricamento asincrono) che trovi in alcune app web Progressivamente Polymer.
Il nostro obiettivo è provare a integrare questi modelli nel PSK nel 2016, ma i primi esperimenti in merito si possono trovare nell'app Polymer Zuperkulblog di Rob Dodson e nell'eccellente Polymer Perf Models parla di Eric Bidelman.
Starter kit web
Il nostro punto di partenza per i nuovi progetti "vanilla" include le seguenti funzionalità delle app web progressive:
- File manifest dell'applicazione web
- Schermata iniziale di Chrome per Android
- Pre-memorizzazione nella cache del personale di servizio 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 con e senza librerie e framework JS. Se sei in cerca di ispirazione, i repository seguenti potrebbero essere utili come riferimento. Sono anche delle dannatamente buone app.
JavaScript vaniglia
- Memo vocali di Paul Lewis è stato realizzato utilizzando un'architettura simile a
app-shell(write-up) - Wikipedia offline di Jake Archibald (video)
- Air Horner di Paul Kinlan
- Guitar Tuner di Paul Lewis (scrittura)
Polymer
- Zuperkulblog di Rob Dodson (slide)
React
- iFixit di Jeff Posnick - utilizza
sw-precacheper la memorizzazione nella cache della shell dell'applicazione (slide)
DOM virtuale
- Pokedex di Nolan Lawson: eccellente app web progressiva che applica un approccio "fai tutto in un lavoratore web" per facilitare il rendering progressivo. (ricorso)
Angular.js
- Timey.in di Kenneth Auchenberg utilizza anche
sw-precacheper la pre-memorizzazione delle risorse nella cache
Note di chiusura
Come accennato, le app web progressive sono ancora agli albori, ma è un momento entusiasmante per sperimentare le metodologie alla loro base e vedere come possono essere applicate alle proprie app web.
Al momento Paul Kinlan sta pianificando le linee guida di Web Fundamentals per le app web progressive. Se hai commenti sulle aree che vorresti approfondire, non esitare a commentare i thread.
Per approfondire
- App web progressive: evitare schede senza perdere l'anima
- Perché le app web progressive sono il futuro dello sviluppo web
- App web progressive: pronte per il lancio
- Creazione di un'app progressiva con ServiceWorker
- Le app web progressive sono il futuro
- App web progressiva: un nuovo modo di provare i dispositivi mobili
- Ti presentiamo Pokedex.org, un'app web progressiva per i fan di Pokémon
- Riepilogo del Chrome Developer Summit: app web progressive