Aan de slag met progressive web-apps

Er is de laatste tijd veel discussie over progressive web-apps. Het is nog een relatief nieuw model, maar de principes kunnen ook apps verbeteren die zijn gebouwd met vanilla JS, React, Polymer, Angular of een ander framework. In deze post vat ik een aantal opties en referentie-apps samen waarmee je vandaag nog aan de slag kunt met je eigen progressive web-app.

Wat is een progressive web-app?

Het is belangrijk om te onthouden dat progressive web-apps overal werken, maar dat ze in moderne browsers extra krachtig zijn. Progressive enhancement is de ruggengraat van het model.

Aaron Gustafson vergeleek progressive enhancement met een pinda-M&M. De pinda is je content, de chocoladelaag is je presentatielaag en je JavaScript is de harde buitenkant. Deze laag kan variëren in kleur en de functionaliteit kan variëren, afhankelijk van de mogelijkheden van de browser die de laag gebruikt.

Je kunt de snoepjeslaag zien als de plek waar veel functies van de progressive web-app zich bevinden. Ze combineren het beste van het web en het beste van apps. Ze zijn nuttig voor gebruikers vanaf het allereerste bezoek in een browsertabblad, zonder dat ze hoeven te worden geïnstalleerd.

Als de gebruiker een relatie met deze apps opbouwt door herhaald gebruik, wordt de candy shell nog zoeter: de apps laden heel snel op langzame netwerkverbindingen (dankzij service worker), sturen relevante pushmeldingen en hebben een eersteklas icoon op het startscherm van de gebruiker dat ze kan laden als app-ervaringen op volledig scherm. Ze kunnen ook gebruikmaken van slimme installatiebanners voor web-apps.

Installatiebanners voor web-apps voor betrokkenheid, starten vanaf het startscherm van de gebruiker, startscherm in Chrome voor Android, werkt offline met servicemedewerker

Progressive web-apps zijn

  • Progressief: Werkt voor elke gebruiker, ongeacht de browserkeuze, omdat ze zijn gemaakt met progressive enhancement als kernprincipe.
  • Responsief: Geschikt voor elke vormfactor, desktop, mobiel, tablet of wat er ook volgt.
  • Onafhankelijk van connectiviteit: Verbeterd met servicemedewerkers om offline of op netwerken van lage kwaliteit te werken.
  • App-achtig: Gebruik het app-shellmodel om navigatie en interacties in app-stijl te bieden.
  • Actueel: Altijd up-to-date dankzij het updateproces van de servicemedewerker.
  • Veilig: Geleverd via TLS om te voorkomen dat iemand meekijkt en om te zorgen dat er niet met de content is geknoeid.
  • Vindbaar: Ze zijn herkenbaar als apps dankzij W3C-manifesten en het registratiebereik van servicemedewerkers, waardoor zoekmachines ze kunnen vinden.
  • Opnieuw aanspreken: Maak het makkelijk om gebruikers opnieuw aan te spreken met functies zoals pushmeldingen.
  • Installeerbaar: Gebruikers kunnen apps die ze het nuttigst vinden, op hun startscherm 'bewaren' zonder gedoe met een appstore.
  • Koppelbaar: Deel makkelijk via een URL zonder complexe installatie.

Progressive Web Apps zijn ook niet uniek voor Chrome voor Android. Hieronder zie je de progressive web-app Pokedex die werkt in Firefox voor Android (bèta) met vroege functies voor Toevoegen aan startscherm en service worker-caching die prima werken.

Progressive web-apps die werken in Firefox voor Android

Een van de leuke aspecten van het progressieve karakter van dit model is dat functies geleidelijk kunnen worden ontgrendeld naarmate browserleveranciers betere ondersteuning bieden. Progressive web-apps zoals Pokedex werken natuurlijk ook prima in Opera op Android, met een paar opmerkelijke verschillen in de implementatie:

Progressive web-apps werken in Opera voor Android

Lees de oorspronkelijke blogpost van Alex Russell waarin hij progressive web-apps introduceert voor meer informatie over progressive web-apps. Paul Kinlan is ook een heel nuttige Stack Overflow-tag gestart voor progressive web-apps die de moeite waard is om te checken.

Principes

Web-app-manifest

Met het manifest kan je web-app een meer native aanwezigheid hebben op het startscherm van de gebruiker. Hiermee kan de app worden gestart in de modus voor volledig scherm (zonder URL-balk), kan de schermstand worden beheerd en kan in recente versies van Chrome op Android een startscherm en themakleur voor de adresbalk worden gedefinieerd. De instelling wordt ook gebruikt om een set iconen te definiëren op basis van grootte en dichtheid die worden gebruikt voor het eerder genoemde startscherm en het icoon op het startscherm.

Toevoegen aan startscherm, starten vanaf startscherm en app-achtige functionaliteit op volledig scherm.

Je vindt een voorbeeldmanifestbestand in de Web Starter Kit en in de Google Chrome-voorbeelden. Bruce Lawson heeft een Manifest Generator geschreven en Mounir Lamouri heeft ook een handige Web Manifest-validator geschreven die de moeite waard is om te bekijken.

In mijn persoonlijke projecten gebruik ik realfavicongenerator om iconen van het juiste formaat te genereren voor zowel het web-app-manifest als voor gebruik op iOS, desktops, enzovoort. De Node-module favicons kan ook een vergelijkbare uitvoer bereiken als onderdeel van je buildproces.

Op Chromium gebaseerde browsers (Chrome, Opera, enzovoort) ondersteunen op dit moment web-app-manifesten. Firefox ontwikkelt actief ondersteuning en Edge vermeldt ze als in overweging. WebKit/Safari hebben nog geen openbare signalen gepost over hun intenties om de functie te implementeren.

Ga naar Installeerbare web-apps met het web-app-manifest in Chrome voor Android op Web Fundamentals voor meer informatie.

Banner Toevoegen aan startscherm

Chrome op Android ondersteunt al een tijdje de mogelijkheid om je site aan het startscherm toe te voegen, maar recente versies ondersteunen ook de mogelijkheid om proactief voor te stellen sites toe te voegen via systeemeigen installatiebanners voor web-apps.

De demo-app voor spraakmemo's toont een prompt voor een installatiebanner voor web-apps in Chrome voor Android

Als je wilt dat de prompts voor app-installatie worden getoond, moet je app aan de volgende vereisten voldoen:

  • Een geldig web-app-manifest hebben
  • Worden weergegeven via HTTPS (ga naar letsencrypt voor een kosteloos certificaat)
  • Een geldige servicemedewerker hebben geregistreerd
  • 2 keer worden bezocht, met minstens 5 minuten tussen de bezoeken

Er zijn een aantal voorbeelden van app-installatiebanners beschikbaar, van basisbanners tot complexere toepassingen, zoals de weergave van gerelateerde apps.

Service worker voor offline caching

Een service worker is een script dat op de achtergrond wordt uitgevoerd, los van je webpagina. De service worker reageert op gebeurtenissen, waaronder netwerkverzoeken die worden gedaan vanaf pagina's die de service worker aanbiedt. Een servicemedewerker heeft een opzettelijk korte levensduur.

De service wordt geactiveerd als deze een gebeurtenis krijgt en wordt alleen uitgevoerd zolang dit nodig is om de gebeurtenis te verwerken. Met een serviceworker kun je de Cache API gebruiken om bronnen te cachen en gebruikers een offline functionaliteit te bieden.

Service workers zijn krachtig voor offline caching, maar ze bieden ook aanzienlijke prestatiewinsten in de vorm van direct laden voor herhaalde bezoeken aan uw site of web-app. U kunt uw app-shell cachen zodat deze offline werkt en de content vullen met JavaScript.

Service worker-caching van de app-shell, zodat deze zonder netwerk kan worden geladen

Er is een uitgebreide set service worker-voorbeelden beschikbaar in Google Chrome-voorbeelden. Het offline kookboek van Jake Archibald is een must-read en ik raad je ten zeerste aan de walkthrough Je eerste offline web-app van Paul Kinlan te proberen als je nog niet bekend bent met serviceworkers.

Ons team onderhoudt ook een aantal hulpprogramma's en buildtools voor serviceworkers die we nuttig vinden om de overhead bij het instellen van serviceworkers te verminderen. Ze staan vermeld in Service Worker Libraries. Dit zijn de 2 belangrijkste:

  • sw-precache: een build-time tool die een service worker-script genereert dat nuttig is om de app-shell van je web-app vooraf te cachen
  • sw-toolbox: een bibliotheek die runtime-caching biedt voor bronnen die niet vaak worden gebruikt

Jeff Posnick heeft een korte introductie over sw-precache geschreven, genaamd Offline-first, fast, with the sw-precache module, en een codelab over dezelfde tool die je misschien nuttig vindt.

Chrome, Opera en Firefox hebben allemaal ondersteuning voor serviceworkers geïmplementeerd. Edge heeft positieve openbare signalen gegeven over interesse in de functie. Safari heeft kort interesse getoond via het voorgestelde vijfjarenplan van een engineer.

Pushmeldingen voor re-engagement

Je kunt dus web-apps maken waarmee gebruikers buiten een tabblad kunnen communiceren. De browser kan worden gesloten en ze hoeven je web-app niet eens actief te gebruiken om je functionaliteit te gebruiken. Voor deze functie zijn zowel een serviceworker als een web-app-manifest vereist, voortbouwend op enkele van de eerder samengevatte functies.

De Push API is geïmplementeerd in Chrome, wordt ontwikkeld in Firefox en wordt overwogen in Edge. Er zijn nog geen openbare signalen van Safari over de intentie om deze functie te implementeren.

Push Notifications on the Open Web is een uitgebreide introductie over hoe je pushmeldingen instelt door Matt Gaunt. Er is ook een codelab voor pushmeldingen beschikbaar op Web Fundamentals.

Pushmelding via het web op de mobiele site van Facebook

Michael van Ouwerkerk van het Chrome-team heeft ook een introductie van 6 minuten over Push als je liever een video bekijkt.

Geavanceerde functies toevoegen

Onthoud dat de gebruikerservaring verschillende niveaus van zoetheid kan hebben, afhankelijk van de browser die wordt gebruikt om je web-app te bekijken. Jij bepaalt de harde buitenkant.

Aanvullende functies die naar het webplatform komen, zoals achtergrondsynchronisatie (voor gegevenssynchronisatie met een server, zelfs als je web-app is gesloten) en Web Bluetooth (voor communicatie met bluetooth-apparaten vanuit je web-app), kunnen op deze manier ook worden toegevoegd aan je Progressive Web App.

Eenmalige achtergrondsynchronisatie is aangezet in Chrome en Jake Archibald heeft een video van zijn Offline Wikipedia-app en een artikel waarin de functie wordt gedemonstreerd. François Beaufort heeft ook een aantal Web Bluetooth-voorbeelden beschikbaar als je die API wilt uitproberen.

Framework-vriendelijk

Er is geen enkele reden waarom je de bovenstaande principes niet zou kunnen toepassen op een bestaande app of een framework waarmee je werkt. Andere principes die je in gedachten moet houden bij het bouwen van je Progressive Web App, zijn het gebruikersgerichte prestatiemodel RAIL en op FLIP gebaseerde animaties.

Ik hoop dat we in 2016 steeds meer boilerplates en seed-projecten zien die ondersteuning voor Progressive Web Apps organisch integreren als kernfunctie. Tot die tijd is de drempel om deze functies aan je eigen apps toe te voegen niet erg hoog en naar mijn mening de moeite waard.

Architectuur

Er zijn verschillende niveaus waarop je 'all-in' kunt gaan met het model voor progressive web-apps, maar een veelgebruikte aanpak is om ze te ontwerpen rond een app-shell. Dit is geen harde vereiste, maar biedt wel verschillende voordelen.

De Application Shell-architectuur stimuleert het opslaan van uw app-shell (de gebruikersinterface) in het cachegeheugen, zodat deze offline werkt en de content wordt ingevuld met JavaScript. Bij herhaalde bezoeken kun je zo heel snel betekenisvolle pixels op het scherm krijgen zonder het netwerk, zelfs als je content uiteindelijk daar vandaan komt. Dit levert aanzienlijke prestatieverbeteringen op.

De app-shell wordt gevisualiseerd als een uitsplitsing van de UI van je app, zoals de lade en het hoofdcontentgebied

Jeremy Keith merkte onlangs op dat in dit type model aan de serverzijde renderen misschien niet als een reserve moet worden beschouwd, maar dat aan de clientzijde renderen als een verbetering moet worden gezien. Dit is terechte feedback.

In het app-shellmodel moet weergave aan de serverzijde zo veel mogelijk worden gebruikt en moet progressieve weergave aan de clientzijde worden gebruikt als een verbetering, op dezelfde manier als we de functionaliteit 'verbeteren' wanneer serviceworker wordt ondersteund. Er zijn veel manieren om dit uiteindelijk aan te pakken.

Ik raad je aan onze beschrijving van de architectuur te lezen en te evalueren hoe je vergelijkbare principes het best kunt toepassen op je eigen app en stack.

Standaardteksten voor aan de slag

App-shell

Op GitHub bekijken

De app-shell-repository bevat een bijna volledige implementatie van de app-shell-architectuur. De backend is geschreven in Express.js en de frontend in ES2015.

Omdat het zowel de client- als de aan de serverzijde van het model omvat en er veel gebeurt, kost het wat tijd om vertrouwd te raken met de codebase. Het is op dit moment ons meest uitgebreide startpunt voor progressive web-apps. Documenten is onze volgende focus voor dit project.

Starterspakket voor Polymer

Op GitHub bekijken

Het officiële startpunt voor Polymer-web-apps ondersteunt de volgende functies voor progressive web-apps:

Polymer-starterspakket met ingebouwde functies voor progressive web-apps

De huidige versie van PSK biedt geen ondersteuning voor sommige van de meer geavanceerde prestatiepatronen (bijv.het app-shell-model, asynchroon laden) die je in sommige progressieve Polymer-web-apps vindt.

We willen deze patronen in 2016 in PSK integreren, maar vroege experimenten hiermee zijn te vinden in de Polymer-app Zuperkulblog van Rob Dodson en de uitstekende presentatie Polymer Perf Patterns van Eric Bidelman.

Web Starter Kit

Op GitHub bekijken

Ons eigenzinnige startpunt voor nieuwe vanilla-projecten bevat de volgende Progressive Web App-functies:

  • Manifest van web-app
  • Startscherm van Chrome voor Android
  • Vooraf opslaan in cachegeheugen van service worker dankzij sw-precache

Als je liever met vanilla JS/ES2015 werkt en Polymer niet kunt gebruiken, kan Web Starter Kit nuttig zijn als referentiepunt dat je kunt hergebruiken of waar je codefragmenten uit kunt halen.

Progressive web-apps met en zonder frameworks

Leden van de community hebben al een aantal open-source Progressive Web Apps gemaakt, zowel met als zonder JS-bibliotheken en -frameworks. Als je inspiratie zoekt, kunnen de onderstaande opslagplaatsen nuttig zijn als referentie. Het zijn ook gewoon heel goede apps.

Progressive web-apps die zijn geïmplementeerd met React, Polymer, Virtual DOM en AngularJS

Vanilla JavaScript

Polymer

Reageren

  • iFixit door Jeff Posnick: gebruikt sw-precache voor caching van app-shells (dia's)

Virtuele DOM

  • Pokedex van Nolan Lawson: een uitstekende progressive web-app die een aanpak van 'alles doen in een webworker' toepast om te helpen met progressieve weergave. (write-up)

Angular.js

  • Timey.in van Kenneth Auchenberg: gebruikt ook sw-precache voor het vooraf cachen van bronnen

Notities voor sluiten

Zoals gezegd staan progressive web-apps nog in de kinderschoenen, maar het is een spannende tijd om te experimenteren met de methodologieën erachter en te zien hoe goed ze kunnen worden toegepast op je eigen web-apps.

Paul Kinlan is momenteel bezig met de planning van de Web Fundamentals-richtlijnen voor Progressive Web Apps. Als je input hebt over gebieden die je graag behandeld wilt zien, kun je reageren op de thread.

Aanvullende informatie