In letzter Zeit gab es viele Diskussionen über progressive Web-Apps. Sie sind noch ein relativ neues Modell, aber ihre Prinzipien können auch Apps verbessern, die mit Vanilla JS, React, Polymer, Angular oder einem anderen Framework erstellt wurden. In diesem Beitrag fasse ich einige Optionen und Referenz-Apps zusammen, mit denen Sie noch heute mit Ihrer eigenen progressiven Web-App beginnen können.
Was ist eine Progressive Web-App?
Progressive Web-Apps funktionieren überall, aber in modernen Browsern sind sie besonders leistungsstark. Progressive Verbesserung ist ein Grundpfeiler des Modells.
Aaron Gustafson verglich die progressive Verbesserung mit einem Erdnuss-M&M. Die Erdnuss ist Ihr Inhalt, die Schokoladenhülle ist Ihre Präsentationsebene und Ihr JavaScript ist die harte Bonbonhülle. Die Farbe dieser Ebene kann variieren und die Darstellung kann je nach den Funktionen des verwendeten Browsers unterschiedlich sein.
Die Bonbonhülle ist der Ort, an dem viele Funktionen von progressiven Web-Apps zu finden sind. Sie kombinieren das Beste aus dem Web und aus Apps. Sie sind für Nutzer ab dem ersten Besuch in einem Browsertab nützlich, ohne dass eine Installation erforderlich ist.
Wenn der Nutzer diese Apps wiederholt verwendet, wird die Bonbonhülle noch süßer – sie werden bei langsamen Netzwerkverbindungen sehr schnell geladen (dank Service Worker), senden relevante Push-Benachrichtigungen und haben ein erstklassiges Symbol auf dem Startbildschirm des Nutzers, über das sie als Vollbild-Apps geladen werden können. Außerdem können sie intelligente Banner für die Installation von Web-Apps nutzen.
Progressive Web-Apps sind
- Progressiv: Sie funktionieren für alle Nutzer, unabhängig vom verwendeten Browser, da sie auf dem Prinzip der progressiven Verbesserung basieren.
- Responsiv: Passt sich an alle Formfaktoren an, egal ob Computer, Mobilgerät, Tablet oder was auch immer als Nächstes kommt.
- Unabhängig von der Verbindung: Dank Service Workern funktionieren sie auch offline oder in Netzwerken mit geringer Qualität.
- App-ähnlich: Verwenden Sie das Anwendungsshell-Modell, um Navigation und Interaktionen im App-Stil bereitzustellen.
- Aktuell: Dank des Service Worker-Aktualisierungsprozesses immer auf dem neuesten Stand.
- Sicher: Die Bereitstellung erfolgt über TLS, um Schnüffeln zu verhindern und sicherzustellen, dass die Inhalte nicht manipuliert wurden.
- Sichtbarkeit: Sie sind dank W3C-Manifesten und dem Registrierungsbereich von Service Workern als „Anwendungen“ identifizierbar, sodass Suchmaschinen sie finden können.
- Erneute Interaktion: Erleichtere die erneute Interaktion durch Funktionen wie Push-Benachrichtigungen.
- Installierbar: Nutzer können Apps, die sie am nützlichsten finden, auf ihrem Startbildschirm „behalten“, ohne einen App-Shop aufrufen zu müssen.
- Verlinkbar: Einfache Freigabe über eine URL, ohne dass eine komplexe Installation erforderlich ist.
Progressive Web-Apps sind auch nicht nur für Chrome für Android verfügbar. Unten sehen Sie die Progressive Web App Pokedex, die in Firefox für Android (Beta) ausgeführt wird. Die frühen Funktionen „Zum Startbildschirm hinzufügen“ und „Service Worker-Caching“ funktionieren einwandfrei.
Einer der Vorteile des „progressiven“ Charakters dieses Modells ist, dass Funktionen nach und nach freigeschaltet werden können, wenn Browseranbieter sie besser unterstützen. Progressive Web-Apps wie Pokedex funktionieren natürlich auch in Opera unter Android hervorragend, wobei es einige bemerkenswerte Unterschiede bei der Implementierung gibt:
Wenn Sie mehr über Progressive Web-Apps erfahren möchten, lesen Sie den ursprünglichen Blogpost von Alex Russell, in dem sie vorgestellt werden. Paul Kinlan hat außerdem ein sehr nützliches Stack Overflow-Tag für Progressive Web-Apps erstellt, das Sie sich ansehen sollten.
Grundsätze
Web-App-Manifest
Das Manifest ermöglicht es, dass deine Web-App auf dem Startbildschirm des Nutzers wie eine native App angezeigt wird. Sie ermöglicht es, die App im Vollbildmodus (ohne URL-Leiste) zu starten, bietet Kontrolle über die Bildschirmausrichtung und unterstützt in neueren Versionen von Chrome unter Android die Definition eines Splash Screens und einer Designfarbe für die Adressleiste. Außerdem wird es verwendet, um eine Reihe von Symbolen nach Größe und Dichte für den oben genannten Ladebildschirm und das Startbildschirmsymbol zu definieren.
Eine Beispiel-Manifestdatei finden Sie im Web Starter Kit und in den Google Chrome-Beispielen. Bruce Lawson hat einen Manifest-Generator geschrieben und Mounir Lamouri hat einen praktischen Web-Manifest-Validator entwickelt, den Sie sich ebenfalls ansehen sollten.
In meinen persönlichen Projekten verwende ich realfavicongenerator, um Symbole in der richtigen Größe sowohl für das Web-App-Manifest als auch für die Verwendung unter iOS, auf dem Desktop usw. zu generieren. Mit dem Node-Modul favicons lässt sich im Rahmen des Build-Prozesses eine ähnliche Ausgabe erzielen.
Chromium-basierte Browser (Chrome, Opera usw.) unterstützen Web-App-Manifeste bereits. Firefox entwickelt derzeit eine Unterstützung und Edge listet sie als in Erwägung gezogen auf. WebKit/Safari haben noch keine öffentlichen Signale zu ihren Absichten zur Implementierung der Funktion veröffentlicht.
Weitere Informationen finden Sie unter Installable Web Apps with the Web App Manifest in Chrome for Android in Web Fundamentals.
Banner „Zum Startbildschirm hinzufügen“
Chrome für Android unterstützt schon seit einiger Zeit das Hinzufügen von Websites zum Startbildschirm. In neueren Versionen werden Websites aber auch proaktiv über native Installationsbanner für Web-Apps vorgeschlagen.
Damit die Aufforderungen zur App-Installation angezeigt werden, muss Ihre App die folgenden Voraussetzungen erfüllen:
- Ein gültiges Web-App-Manifest haben
- Über HTTPS bereitgestellt werden (ein kostenloses Zertifikat finden Sie unter letsencrypt)
- Gültigen Service Worker registriert haben
- Zweimal besucht werden, wobei zwischen den Besuchen mindestens 5 Minuten liegen müssen
Es gibt eine Reihe von Beispielen für App-Installationsbanner, von einfachen Bannern bis hin zu komplexeren Anwendungsfällen wie der Anzeige ähnlicher Apps.
Service Worker für Offline-Caching
Ein Service Worker ist ein Skript, das im Hintergrund und unabhängig von Ihrer Webseite ausgeführt wird. Er reagiert auf Ereignisse, einschließlich Netzwerkanfragen, die von Seiten gestellt werden, die er bereitstellt. Ein Service Worker hat eine absichtlich kurze Lebensdauer.
Sie wird aktiviert, wenn sie ein Ereignis empfängt, und wird nur so lange ausgeführt, wie es für die Verarbeitung des Ereignisses erforderlich ist. Mit Service Workern können Sie die Cache API verwenden, um Ressourcen im Cache zu speichern und Nutzern eine Offline-Nutzung zu ermöglichen.
Service Worker sind leistungsstark für das Offline-Caching, bieten aber auch erhebliche Leistungsvorteile in Form von sofortigem Laden bei wiederholten Besuchen Ihrer Website oder Web-App. Sie können Ihre Anwendungsshell so im Cache speichern, dass sie offline funktioniert, und ihren Inhalt mit JavaScript füllen.
Eine umfassende Sammlung von Service Worker-Beispielen finden Sie unter „Google Chrome-Beispiele“. Das Offline-Kochbuch von Jake Archibald ist ein Muss. Wenn Sie noch keine Erfahrung mit Service Workern haben, empfehlen wir Ihnen außerdem die Anleitung Ihre erste Offline-Web-App von Paul Kinlan.
Unser Team pflegt auch eine Reihe von Dienstprogrammen und Build-Tools für Service Worker, die wir für nützlich halten, um den Aufwand für die Einrichtung von Service Workern zu reduzieren. Sie sind unter Service Worker-Bibliotheken aufgeführt. Die beiden wichtigsten sind:
- sw-precache: Ein Build-Tool, das ein Service Worker-Script generiert, das für das Precaching der Anwendungsshell Ihrer Web-App nützlich ist.
- sw-toolbox: Eine Bibliothek, die Laufzeit-Caching für selten verwendete Ressourcen bietet.
Jeff Posnick hat eine kurze Einführung in sw-precache mit dem Titel Offline-first, fast, with the sw-precache module und ein Codelab zu demselben Tool verfasst, die Sie vielleicht nützlich finden.
Chrome, Opera und Firefox unterstützen Service Worker bereits. Edge hat öffentlich Interesse an der Funktion bekundet. Safari hat kurz Interesse daran bekundet, und zwar im Fünfjahresplan eines Entwicklers.
Push-Benachrichtigungen zur erneuten Interaktion
Sie können Web-Apps erstellen, mit denen Nutzer außerhalb eines Tabs interagieren können. Der Browser kann geschlossen werden und die Nutzer müssen Ihre Web-App nicht einmal aktiv verwenden, um mit Ihrer App zu interagieren. Für diese Funktion sind sowohl ein Service Worker als auch ein Web-App-Manifest erforderlich. Sie baut auf einigen der zuvor zusammengefassten Funktionen auf.
Die Push API ist in Chrome implementiert, wird in Firefox entwickelt und für Edge in Betracht gezogen. Es gibt noch keine öffentlichen Signale von Safari, dass diese Funktion implementiert werden soll.
Push Notifications on the Open Web ist eine umfassende Einführung in die Einrichtung von Push-Benachrichtigungen von Matt Gaunt. Außerdem ist ein Codelab zu Push-Benachrichtigungen in den Web Fundamentals verfügbar.
Michael van Ouwerkerk vom Chrome-Team hat auch eine 6-minütige Einführung in Push-Benachrichtigungen erstellt, falls Sie sich lieber ein Video ansehen möchten.
Erweiterte Funktionen hinzufügen
Denken Sie daran, dass die User Experience je nach Browser, der zum Aufrufen Ihrer Web-App verwendet wird, unterschiedlich sein kann. Sie haben die Kontrolle über die harte Bonbonschale.
Zusätzliche Funktionen, die für die Webplattform verfügbar sind, wie die Hintergrundsynchronisierung (für die Datensynchronisierung mit einem Server, auch wenn Ihre Web-App geschlossen ist) und Web Bluetooth (für die Kommunikation mit Bluetooth-Geräten über Ihre Web-App), können auf diese Weise ebenfalls in Ihre Progressive Web-App integriert werden.
Die einmalige Hintergrundsynchronisierung wurde in Chrome aktiviert. Jake Archibald hat ein Video zu seiner Offline-Wikipedia-App und einen Artikel veröffentlicht, in dem er die Funktion demonstriert. François Beaufort bietet auch eine Reihe von Web Bluetooth-Beispielen an, falls Sie diese API ausprobieren möchten.
Framework-freundlich
Es spricht nichts dagegen, die oben genannten Prinzipien auf eine vorhandene Anwendung oder ein Framework anzuwenden, mit dem Sie arbeiten. Weitere Prinzipien, die Sie beim Erstellen Ihrer Progressive Web App beachten sollten, sind das nutzerorientierte Leistungsmodell RAIL und FLIP-basierte Animationen.
Ich hoffe, dass wir 2016 immer mehr Boilerplates und Seed-Projekte sehen werden, die die Unterstützung für progressive Web-Apps als Hauptfunktion integrieren. Bis dahin ist die Hürde, diese Funktionen in Ihre eigenen Apps einzubinden, nicht sehr hoch und meiner Meinung nach den Aufwand wert.
Architektur
Es gibt verschiedene Möglichkeiten, wie weit man das Modell der progressiven Web-App umsetzt. Ein gängiger Ansatz ist jedoch, sie um eine Anwendungsshell herum zu strukturieren. Dies ist keine zwingende Voraussetzung, bietet aber mehrere Vorteile.
Die Anwendungsshell-Architektur fördert das Caching Ihrer Anwendungsshell (der Benutzeroberfläche), damit sie offline funktioniert und ihre Inhalte mithilfe von JavaScript gefüllt werden. Bei wiederholten Besuchen können Sie so sehr schnell und ohne Netzwerk sinnvolle Pixel auf dem Bildschirm anzeigen lassen, auch wenn Ihre Inhalte letztendlich von dort stammen. Dies führt zu erheblichen Leistungssteigerungen.
Jeremy Keith hat kürzlich angemerkt, dass bei dieser Art von Modell das serverseitige Rendering vielleicht nicht als Fallback, sondern das clientseitige Rendering als Verbesserung angesehen werden sollte. Das ist ein berechtigtes Feedback.
Im Anwendungsshell-Modell sollte das serverseitige Rendering so weit wie möglich verwendet werden. Das clientseitige progressive Rendering sollte als Verbesserung verwendet werden, so wie wir die Nutzererfahrung „verbessern“, wenn Service Worker unterstützt werden. Es gibt viele Möglichkeiten, wie Sie dieses Problem letztendlich angehen können.
Ich empfehle Ihnen, unseren Artikel zur Architektur zu lesen und zu prüfen, wie ähnliche Prinzipien am besten auf Ihre eigene Anwendung und Ihren Stack angewendet werden können.
Boilerplates für den Einstieg
Anwendungsshell
Das Repository app-shell enthält eine nahezu vollständige Implementierung der Anwendungsshell-Architektur. Das Backend ist in Express.js und das Frontend in ES2015 geschrieben.
Da es sowohl die client- als auch die serverseitigen Teile des Modells abdeckt und dort ziemlich viel passiert, wird es einige Zeit dauern, bis Sie sich mit der Codebasis vertraut gemacht haben. Ansonsten ist es derzeit unser umfassendster Ausgangspunkt für Progressive Web-Apps. Als Nächstes konzentrieren wir uns bei diesem Projekt auf Docs.
Polymer-Starterkit
Der offizielle Ausgangspunkt für Polymer-Web-Apps unterstützt die folgenden Funktionen für progressive Web-Apps:
- Web-App-Manifest
- Chrome für Android-Startbildschirm
- Offline-Caching von Service Workern mit den Platinum SW-Elementen
- Push-Benachrichtigungen (manuelle Einrichtung erforderlich) mit den Platinum Push-Elementen
In der aktuellen Version von PSK fehlt die Unterstützung für einige der erweiterten Leistungsmuster (z. B. Anwendungsshell-Modell, asynchrones Laden), die in einigen progressiven Polymer-Web-Apps zu finden sind.
Wir möchten diese Muster 2016 in PSK integrieren. Erste Experimente dazu finden Sie in der Polymer-App Zuperkulblog von Rob Dodson und im hervorragenden Vortrag Polymer Perf Patterns von Eric Bidelman.
Web Starter Kit
Unser Ausgangspunkt für neue Vanilla-Projekte umfasst die folgenden Progressive Web App-Funktionen:
- Webanwendungsmanifest
- Chrome für Android-Startbildschirm
- Pre-Caching von Service Workern dank sw-precache
Wenn Sie lieber mit Vanilla JS/ES2015 arbeiten und Polymer nicht verwenden können, kann das Web Starter Kit als Referenz dienen, die Sie wiederverwenden oder aus der Sie Code-Snippets übernehmen können.
Progressive Web-Apps mit und ohne Frameworks
Mitglieder der Community haben bereits eine Reihe von Open-Source-Progressive Web-Apps mit und ohne JS-Bibliotheken und -Frameworks erstellt. Wenn Sie nach Inspiration suchen, können die folgenden Repositories als Referenz nützlich sein. Außerdem sind es einfach verdammt gute Apps.
Vanilla JavaScript
- Voice Memos von Paul Lewis basiert auf einer ähnlichen Architektur wie
app-shell(Bericht). - Offline Wikipedia von Jake Archibald (Video)
- Air Horner von Paul Kinlan
- Guitar Tuner von Paul Lewis (Beschreibung)
Polymer
- Zuperkulblog von Rob Dodson (Folien)
React
Virtuelles DOM
- Pokedex von Nolan Lawson – eine hervorragende progressive Web-App, die einen „Alles in einem Web Worker“-Ansatz verwendet, um das progressive Rendering zu unterstützen. (Bericht)
Angular.js
- Timey.in von Kenneth Auchenberg – verwendet ebenfalls
sw-precachefür das Precaching von Ressourcen
Schlussbemerkungen
Wie bereits erwähnt, befinden sich progressive Web-Apps noch in den Kinderschuhen. Es ist jedoch eine spannende Zeit, um mit den dahinterstehenden Methoden zu experimentieren und zu sehen, wie gut sie sich auf Ihre eigenen Web-Apps anwenden lassen.
Paul Kinlan plant derzeit die Web Fundamentals-Anleitung zu progressiven Web-Apps. Wenn ihr Vorschläge zu Bereichen habt, die abgedeckt werden sollten, könnt ihr gerne einen Kommentar im Thread hinterlassen.
Weitere Informationen
- Progressive Web-Apps: Tabs verlassen, ohne die Seele zu verlieren
- Why Progressive Web Apps Are The Future Of Web Development (Warum Progressive Web-Apps die Zukunft der Webentwicklung sind)
- Progressive Web-Apps: bereit für die Primetime
- Progressive Web-App mit ServiceWorker erstellen
- Progressive Web-Apps sind die Zukunft
- Progressive Web-App: Eine neue Art, das Web auf Mobilgeräten zu nutzen
- Introducing Pokedex.org: a progressive webapp for Pokémon fans
- Chrome Developer Summit Recap: Progressive Web Apps