Di recente si sono discusse molto positivamente le app web progressive. Si tratta comunque di un modello relativamente nuovo, ma i suoi principi possono migliorare ugualmente le app create con vanilla JS, React, Polymer, Angular o qualsiasi altro framework. In questo post riassumerò alcune opzioni e farò riferimento alle app per iniziare subito a utilizzare 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 color arachidi. L'arachide è il tuo contenuto, il rivestimento di cioccolato è il tuo livello di presentazione e il tuo JavaScript è il guscio duro della caramella. Questo livello può variare a colori e l'esperienza può variare a seconda delle funzionalità del browser che lo utilizza.
Pensa alla shell di caramelle come al posto in cui possono risiedere molte funzionalità delle app web progressive. Sono esperienze che uniscono 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.
Poiché l'utente instaura una relazione con queste app tramite l'uso ripetuto, rende ancora più dolce la shell di caramelle: si carica molto velocemente su connessioni di rete lente (grazie al service worker), invia notifiche push pertinenti e visualizza un'icona di prim'ordine sulla schermata Home dell'utente che può caricarle come esperienze con le app a schermo intero. Inoltre, possono usufruire dei banner per l'installazione di app web intelligenti.
Le Progressive Web App sono
- Progressiva: lavora per tutti gli utenti, indipendentemente dalla scelta del browser, perché sono stati creati con il miglioramento progressivo come tenant principale.
- Adattabile: si adatta a qualsiasi fattore di forma, computer, dispositivo mobile, tablet o qualsiasi altro dispositivo.
- Indipendente dalla connettività: potenziato con i service worker per il funzionamento offline o su reti di bassa qualità.
- Tipo di app: viene utilizzato il modello shell dell'app per fornire navigazioni e interazioni in stile app.
- Aggiornato: 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 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.
- Installabili: consenti agli utenti di "conservare" le app che ritengono più utili nella schermata Home, senza doversi preoccupare di uno store.
- Collegabile: condividi facilmente tramite URL senza richiedere un'installazione complessa.
Inoltre, le app web progressive non sono esclusive di Chrome per Android. Di seguito possiamo vedere l'app web progressiva Pokedex che funziona in Firefox per Android (beta) con le prime funzionalità di aggiunta alla schermata Home e di memorizzazione nella cache del service worker che funzionano correttamente.
Uno degli aspetti positivi della natura "progressiva" di questo modello è che le funzionalità possono essere sbloccate gradualmente man mano che i fornitori di browser forniscono un migliore supporto. Le app web progressive come Pokedex, ovviamente, funzionano perfettamente anche in Opera su Android con alcune note differenze nell'implementazione:
Per approfondire l'argomento delle applicazioni web progressive, leggi il post del blog originale di Alex Russell in cui vengono presentate. Paul Kinlan ha anche introdotto un tag Stack Overflow molto utile per le app web progressive che vale la pena provare.
Princìpi
File manifest dell'app web
Il file manifest consente alla tua app web di avere una presenza più nativa nella schermata Home dell'utente. Consente l'avvio dell'app in modalità a schermo intero (senza la barra dell'URL), consente di controllare l'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 inoltre utilizzato per definire un insieme di icone per dimensioni e densità utilizzato per le icone della schermata iniziale e della schermata Home.
Un file manifest di esempio è disponibile in Web Starter Kit e negli esempi di Google Chrome. Bruce Lawson ha scritto un generatore di file manifest e Mounir Lamouri ha scritto anche un pratico strumento di convalida dei manifest web che vale la pena provare.
Nei miei progetti personali, faccio affidamento su realfavicongenerator per generare le icone delle dimensioni corrette sia per il manifest dell'app web che per l'utilizzo su iOS, desktop e così via. Anche il modulo Nodo favicon è in grado di ottenere un output simile nell'ambito del processo di compilazione.
I browser basati su Chromium (Chrome, Opera e così via) supportano attualmente i file manifest delle app web, con Firefox che sviluppa attivamente il supporto ed Edge li elenca come in considerazione. WebKit/Safari non hanno ancora pubblicato segnali pubblici in merito all'intenzione di implementare la funzionalità.
Per maggiori dettagli, leggi l'articolo App web installabili con il manifest delle app web in Chrome per Android su Web Fundamentals.
Banner "Aggiungi alla schermata Home"
Chrome su Android supporta l'aggiunta dei siti alla schermata Home già da un po' di tempo, ma le versioni più recenti supportano anche il suggerimento proattivo di siti da aggiungere utilizzando banner per l'installazione di app web nativi.
Per poter visualizzare le richieste di installazione dell'app, l'app deve:
- Avere un manifest dell'app web valido
- Essere gestite tramite HTTPS (vedi letsencrypt per un certificato senza costi)
- Disporre di un service worker valido registrato
- Essere stata visitata due volte, a distanza di 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, separato dalla pagina web. Risponde agli eventi, incluse le richieste di rete effettuate dalle pagine pubblicate. Un service worker ha una vita volutamente breve.
Si attiva quando riceve un evento e viene eseguito solo per il tempo necessario a elaborarlo. Il service worker ti consente di utilizzare l'API Cache per memorizzare le risorse nella cache e può essere utilizzato per fornire 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 sotto forma di caricamento istantaneo per visite ripetute al sito o all'applicazione web. Puoi memorizzare nella cache la shell dell'applicazione in modo che funzioni offline e popolare i relativi contenuti utilizzando JavaScript.
Negli esempi di Google Chrome è disponibile una serie completa di esempi di service worker. Il libro di ricette offline di Jake Archibald è imperdibile e ti consiglio vivamente di provare la procedura dettagliata di Paul Kinlan la tua prima app web offline se non conosce ancora il service worker.
Il nostro team gestisce inoltre numerose utilità per service worker e crea strumenti che riteniamo utili per ridurre i costi di configurazione dei Service worker. Sono elencate in Librerie di Service Worker. I due principali sono:
- sw-precache: uno strumento in fase di compilazione che genera uno script del service worker utile per memorizzare nella cache la shell dell'app web.
- sw-toolbox: una libreria che fornisce la memorizzazione nella cache di runtime per risorse utilizzate raramente
Jeff Posnick ha scritto una breve introduzione a sw-precache intitolata Offline-first, fast, with the sw-precache form e un codelab sullo stesso strumento che potresti trovare utile.
Chrome, Opera e Firefox hanno implementato il supporto per i service worker e Edge ha segnali pubblici positivi sull'interesse per questa funzionalità. Safari ha brevemente accennato al suo interesse tramite il piano quinquennale proposto da un ingegnere.
Notifiche push per il ricoinvolgimento
In modo efficace, puoi creare app web con cui gli utenti possono interagire al di fuori di una scheda. Il browser può essere chiuso e non è necessario che utilizzi attivamente l'app web per interagire con la tua esperienza. La funzionalità richiede sia un service worker sia un manifest dell'app web, basato su alcune delle funzionalità riassunte in precedenza.
L'API Push viene implementata in Chrome, in fase di sviluppo in Firefox e in considerazione in Edge. Non ci sono ancora indicatori pubblici di Safari circa l'intenzione di implementare questa funzionalità per il momento.
Le notifiche push sul web aperto sono un'introduzione esaustiva alla configurazione delle notifiche push da parte di Matt Gaunt. Inoltre, su Web Fundamentals è disponibile un codelab sulle notifiche push.
Anche Michael van Ouwerkerk del team di Chrome ha un'introduzione di 6 minuti a Push se preferisci usare i video.
Combinazione di funzionalità avanzate
Ricorda che l'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 della shell dura.
Ulteriori funzionalità disponibili 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 dispositivi Bluetooth dall'app web), possono essere aggiunte in questo modo all'app web progressiva.
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 lo mostra in azione. Francois Beaufort ha anche a disposizione una serie di esempi di Web Bluetooth se ti interessa provare quell'API.
Ottimizzato per il framework
Non c'è davvero nulla che ti impedisca di applicare questi principi a un'applicazione o a un framework esistenti con cui stai creando. Altri principi da tenere a mente durante la realizzazione della tua app web progressiva sono il modello di rendimento incentrato sull'utente RAIL e le animazioni basate su FLIP.
Spero che nel corso del 2016 vedremo un numero crescente di boilerplates e progetti di origine cuocere in modo organico nel supporto delle applicazioni web progressive come funzionalità principale. Fino ad allora, l'ostacolo all'aggiunta di queste funzionalità alle tue app non è molto alto e vale la pena fare.
Architettura
Esistono diversi livelli di "tutto compreso" per il modello di app web progressive, ma un approccio comune adottato è progettarli intorno a una shell dell'applicazione. Non si tratta di un requisito obbligatorio, ma offre numerosi 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 completi i relativi contenuti utilizzando JavaScript. Durante le visite ripetute, questo ti consente di visualizzare pixel significativi sullo schermo molto rapidamente senza rete, anche se i tuoi contenuti provengono da lì. Questo comporta miglioramenti significativi del rendimento.
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 equo.
Nel modello Application Shell, il rendering lato server dovrebbe essere utilizzato il più possibile e il rendering progressivo lato client dovrebbe essere utilizzato come miglioramento nello stesso modo in cui "miglioriamo" l'esperienza quando è supportato il service worker. Alla fine, ci sono molti modi per affrontare questo aspetto.
Ti consiglio di leggere il nostro riepilogo sull'architettura e di valutare come principi simili potrebbero essere applicati al meglio alla tua applicazione e al tuo stack.
Introduzione ai boilerplates
Shell dell'applicazione
Il repository app-shell contiene un'implementazione quasi completa dell'architettura della shell di applicazione. Ha un backend scritto in Express.js e un front-end scritto in ES2015.
Dato che copre le parti del modello sia client che lato server e c'è molto da fare, ci vorrà un po' di tempo per familiarizzare con il codebase. Si tratta del punto di partenza per le app web progressive più completo in questo momento. Il prossimo argomento di questo progetto sarà Documenti.
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 del service worker con gli elementi SW Platinum
- Notifiche push (è richiesta la configurazione manuale) con gli elementi push Platinum
La versione attuale di PSK non supporta alcuni dei pattern di prestazioni più avanzati (ad es.il modello Application Shell, il caricamento asincrono) che trovi in alcune app web Progressive Polymer.
Vogliamo provare a integrare questi pattern in PSK nel 2016, ma i primi esperimenti in merito si possono trovare nell'app Polymer Zuperkulblog di Rob Dodson e nell'eccellente discorso Polymer Perf Patterns di Eric Bidelman.
Kit iniziale 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 del service worker grazie a sw-precache
Se preferisci lavorare con JS/ES2015 Vanilla e non puoi usare Polymer, il Web Starter Kit potrebbe esserti utile come punto di riferimento da cui puoi riutilizzare o da cui puoi sottrarre snippet di codice.
App web progressive con e senza framework
Un certo numero di applicazioni web progressive open source sono già state create dai membri della community con e senza librerie e framework JS. Se sei in cerca di ispirazione, i repository riportati di seguito potrebbero esserti utili come riferimento. Sono anche dannatamente buone app.
JavaScript vaniglia
- I memo vocali di Paul Lewis sono stati realizzati utilizzando un'architettura simile a quella di
app-shell(scrittura in corso) - Wikipedia offline di Jake Archibald (video)
- Air Horner di Paul Kinlan
- Guitar Tuner di Paul Lewis (write-up)
Polymer
- Zuperkulblog di Rob Dodson (diapositive)
React
- iFixit di Jeff Posnick - utilizza
sw-precacheper la memorizzazione nella cache della shell dell'applicazione (diapositive)
DOM virtuale
- Pokedex di Nolan Lawson: eccellente app web progressiva che applica un approccio "fai tutto in un web worker" per migliorare il rendering progressivo. (scrittura)
Angular.js
- Timey.in di Kenneth Auchenberg. Utilizza anche
sw-precacheper la pre-memorizzazione delle risorse nella cache
Note di chiusura
Come accennato, le applicazioni web progressive sono ancora agli albori, ma sono un momento entusiasmante per sperimentare le metodologie su cui si basano e vedere come possono applicarsi alle proprie app web.
Paul Kinlan attualmente sta pianificando le linee guida di Web Fundamentals sulle applicazioni web progressive e, se hai commenti sulle aree che vorresti che fossero trattate, non esitare a commentarle in thread.
Per approfondire
- App web progressive: abbandonare le schede senza perdere l'anima
- Perché le app web progressive sono il futuro dello sviluppo web
- App web progressive: pronte per la prima serata
- Creare un'app progressiva con ServiceWorker
- Le app web progressive sono il futuro
- App web progressiva: un nuovo modo di utilizzare 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