In letzter Zeit gab es viele interessante Diskussionen über progressive Web-Apps. Sie sind zwar noch ein relativ neues Modell, aber ihre Prinzipien können gleichermaßen Apps verbessern, die mit Vanilla JS, React, Polymer, Angular oder einem anderen Framework erstellt wurden. In diesem Beitrag fasse ich einige Optionen und Anwendungen zusammen, die Ihnen den Einstieg in Ihre eigene progressive Web-App erleichtern.
Was ist eine progressive Web-App?
Progressive Web-Apps funktionieren überall, sind aber in modernen Browsern besonders leistungsstark. Progressive Verbesserung ist ein Grundpfeiler des Modells.
Aaron Gustafson verglich progressive Verbesserung mit einem Erdnuss-M&M. Die Erdnuss steht für Ihre Inhalte, die Schokoladenschicht für die Präsentationsschicht und Ihr JavaScript für die Hartbonbon-Schale. Die Farbe dieser Schicht kann variieren und die Darstellung kann je nach den Funktionen des Browsers, der sie verwendet, variieren.
Sie können sich die Schokoschale als den Ort vorstellen, an dem viele Funktionen progressiver Web-Apps verfügbar sind. Sie kombinieren die besten Funktionen des Webs und von Apps. Sie sind für Nutzer bereits beim ersten Besuch in einem Browsertab nützlich und müssen nicht installiert werden.
Wenn der Nutzer durch wiederholte Nutzung eine Beziehung zu diesen Apps aufbaut, werden sie noch attraktiver: Sie laden dank Service Worker sehr schnell bei langsamen Netzwerkverbindungen, senden relevante Push-Benachrichtigungen und haben ein erstklassiges Symbol auf dem Startbildschirm des Nutzers, über das sie als Vollbild-App geladen werden können. Außerdem können sie intelligente Web-App-Installationsbanner nutzen.
Progressive Web-Apps sind
- Progressiv: Sie funktionieren für alle Nutzer unabhängig von der Browserauswahl, da sie mit progressiver Verbesserung als Kernelement entwickelt wurden.
- Responsiv – passen Sie alle Formfaktoren an, ob Computer, Smartphone, Tablet oder irgendetwas anderes.
- Verbindungsunabhängig – Durch Service Worker funktioniert ein Kubeflow-Deployment auch offline oder in Netzwerken mit geringer Qualität.
- App-ähnlich: Das App-Shell-Modell wird verwendet, um Navigationsfunktionen und Interaktionen im App-Stil bereitzustellen.
- Aktuell – Dank des Service Worker-Aktualisierungsprozesses immer auf dem neuesten Stand
- Sicher: Wird über TLS bereitgestellt, um das Ausspionieren zu verhindern und dafür zu sorgen, dass die Inhalte nicht manipuliert wurden.
- Sichtbar – sind dank W3C-Manifesten und Service Worker-Registrierungsbereich als „Anwendungen“ identifizierbar, sodass sie von Suchmaschinen gefunden werden können.
- Erneute Interaktionen: Einfachere erneute Interaktionen durch Funktionen wie Push-Benachrichtigungen
- Installierbar: Nutzer können die nützlichsten Apps auf dem Startbildschirm speichern, ohne sich durch einen App-Shop klicken zu müssen.
- Linkbar: Sie können sie ganz einfach über eine URL teilen und es ist keine komplexe Installation erforderlich.
Progressive Web-Apps sind auch nicht nur für Chrome für Android verfügbar. Unten sehen Sie die progressive Web-App Pokedex in Firefox für Android (Beta). Die Funktionen „Zum Startbildschirm hinzufügen“ und „Service Worker-Caching“ funktionieren einwandfrei.
Ein Vorteil dieses progressiven Modells ist, dass Funktionen nach und nach freigeschaltet werden können, sobald Browseranbieter eine bessere Unterstützung dafür anbieten. Progressive Web-Apps wie Pokedex funktionieren natürlich auch in Opera auf Android-Geräten hervorragend, mit einigen erwähnenswerten Unterschieden bei der Implementierung:
Weitere Informationen zu progressiven Web-Apps finden Sie im ursprünglichen Blogpost von Alex Russell. Paul Kinlan hat auch ein sehr nützliches Stack Overflow-Tag für progressive Web-Apps erstellt, das sich lohnt.
Grundsätze
Web-App-Manifest
Das Manifest ermöglicht es Ihrer Webanwendung, auf dem Startbildschirm des Nutzers eine nativere Präsenz zu haben. So kann die App im Vollbildmodus gestartet werden (ohne URL-Leiste), die Bildschirmausrichtung kann gesteuert werden und in den neuesten Versionen von Chrome auf Android können ein Startbildschirm und eine Designfarbe für die Adressleiste definiert werden. Außerdem wird damit eine Reihe von Symbolen nach Größe und Dichte definiert, die für den oben genannten Ladebildschirm und das Startbildschirmsymbol verwendet werden.
Eine Beispielmanifestdatei finden Sie im Web Starter Kit und in den Google Chrome-Beispielen. Bruce Lawson hat einen Manifest-Generator entwickelt und Mounir Lamouri hat einen praktischen Web-Manifest-Validator geschrieben, den Sie sich ansehen sollten.
In meinen persönlichen Projekten verwende ich realfavicongenerator, um Symbole in der richtigen Größe für das Manifest der Webanwendung und für die Verwendung auf iOS-Geräten, Computern usw. zu generieren. Mit dem Node-Modul favicons lässt sich im Rahmen des Build-Prozesses eine ähnliche Ausgabe erzielen.
Chromium-basierte Browser (z. B. Chrome und Opera) unterstützen Web-App-Manifeste. Firefox arbeitet aktiv an der Unterstützung und Edge führt sie als in Erwägung gezogen auf. WebKit/Safari hat noch keine öffentlichen Signale über die Absichten der Implementierung der Funktion veröffentlicht.
Weitere Informationen finden Sie unter Web Fundamentals im Artikel Installierbare Web-Apps mit dem Web-App-Manifest in Chrome für Android.
Banner „Zum Startbildschirm hinzufügen“
In Chrome für Android können Sie Ihre Website schon seit einiger Zeit auf dem Startbildschirm hinzufügen. In den neuesten Versionen werden aber auch proaktiv Websites über native Installationsbanner für Web-Apps vorgeschlagen.
Damit die Aufforderungen zur App-Installation angezeigt werden, muss Ihre App folgende Voraussetzungen erfüllen:
- Gültiges Web-App-Manifest
- über HTTPS bereitgestellt werden (siehe letsencrypt für ein kostenloses Zertifikat)
- Es muss ein gültiger Service Worker registriert sein
- Sie müssen zweimal besucht werden, wobei zwischen den Besuchen mindestens 5 Minuten liegen müssen.
Es gibt eine Reihe von Beispielen für App-Installationsbanner, die von einfachen Bannern bis hin zu komplexeren Anwendungsfällen wie der Darstellung ähnlicher Apps reichen.
Service Worker für Offline-Caching
Ein Service Worker ist ein Script, das im Hintergrund und unabhängig von Ihrer Webseite ausgeführt wird. Er reagiert auf Ereignisse, einschließlich Netzwerkanfragen von Seiten, die er ausliefert. Ein Dienst-Worker hat eine absichtlich kurze Lebensdauer.
Er wird aktiviert, wenn ein Termin empfangen wird, und wird nur so lange ausgeführt, wie er benötigt, um ihn zu verarbeiten. Mit Service Worker können Sie die Cache API verwenden, um Ressourcen im Cache zu speichern und Nutzern eine Offlinefunktion zur Verfügung zu stellen.
Service Worker sind für das Offline-Caching leistungsstark, bieten jedoch auch erhebliche Leistungssteigerungen, da sie bei wiederholten Besuchen Ihrer Website oder Webanwendung sofort geladen werden. Sie können Ihre Anwendungs-Shell im Cache speichern, sodass sie offline funktioniert und deren Inhalt mit JavaScript dargestellt wird.
Über Google Chrome steht eine umfassende Reihe von Service Worker-Beispielen zur Verfügung. Das Offline-Kochbuch von Jake Archibald ist ein Muss. Wenn Sie noch keine Erfahrung mit Service Workern haben, empfehle ich Ihnen die Anleitung Ihre erste Offline-Web-App von Paul Kinlan.
Unser Team verwaltet auch eine Reihe von Dienstmitarbeiter-Hilfsprogrammen und Build-Tools, die wir für die Einrichtung von Dienstmitarbeitern nützlich finden. Sie sind unter Service Worker Libraries aufgeführt. Die zwei wichtigsten sind:
- sw-precache: Ein Tool zur Buildzeit, das ein Service Worker-Script generiert, das zum Precaching der Webanwendungs-Shell verwendet werden kann
- 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 (Offline-first, schnell, mit dem sw-precache-Modul) und ein Codelab zu demselben Tool verfasst, die Ihnen nützlich sein könnten.
Chrome, Opera und Firefox haben die Unterstützung für Service Worker implementiert. Edge hat positive öffentliche Signale zum Interesse an der Funktion gesendet. Safari hat kurz Interesse daran erwähnt, indem ein Entwickler einen Fünfjahresplan vorgeschlagen hat.
Push-Benachrichtigungen für erneute Interaktion
Sie können also Web-Apps erstellen, mit denen Nutzer auch außerhalb eines Tabs interagieren können. Der Browser kann geschlossen sein und der Nutzer muss Ihre Webanwendung nicht einmal aktiv verwenden, um mit Ihrer Website zu interagieren. Die Funktion erfordert sowohl einen Service Worker als auch ein Web-App-Manifest, das auf einigen der zuvor zusammengefassten Funktionen aufbaut.
Die Push API ist in Chrome implementiert, in Firefox in der Entwicklung und in Edge in Erwägung. Es gibt derzeit keine öffentlichen Signale von Safari, dass diese Funktion implementiert werden soll.
Push-Benachrichtigungen im offenen Web ist eine umfassende Einführung in die Einrichtung von Push-Benachrichtigungen von Matt Gaunt. Außerdem ist auf Web Fundamentals ein Codelab zu Push-Benachrichtigungen verfügbar.
Michael van Ouwerkerk vom Chrome-Team hat auch eine 6-minütige Einleitung zu „Push“, wenn du eher Videos neigst.
Überlagerung in erweiterten Funktionen
Denken Sie daran, dass die Nutzerfreundlichkeit je nach Browser, mit dem Ihre Webanwendung aufgerufen wird, unterschiedlich sein kann. Sie haben die Kontrolle über die Hartbonbon-Hülle.
Zusätzliche Funktionen, die auf der Webplattform eingeführt werden, wie die Hintergrundsynchronisierung (für die Datensynchronisierung mit einem Server, auch wenn Ihre Webanwendung geschlossen ist) und Web Bluetooth (für die Kommunikation mit Bluetooth-Geräten über Ihre Webanwendung) können auf diese Weise in Ihre progressive Webanwendung eingefügt werden.
Die One-Shot-Hintergrundsynchronisierung wurde in Chrome aktiviert. Jake Archibald hat ein Video seiner Offline-Wikipedia-App und einen Artikel hochgeladen, in dem er die Funktionsweise der App demonstriert. François Beaufort stellt auch eine Reihe von Web Bluetooth-Beispielen zur Verfügung, wenn Sie diese API ausprobieren möchten.
Framework-freundlich
Die oben genannten Prinzipien können Sie auf eine vorhandene Anwendung oder ein vorhandenes Framework anwenden, mit dem Sie arbeiten. Weitere Prinzipien, die Sie beim Erstellen Ihrer progressiven Webanwendung beachten sollten, sind das nutzerorientierte Leistungsmodell RAIL und FLIP-basierte Animationen.
Ich bin zuversichtlich, dass im Jahr 2016 eine zunehmende Anzahl von Standardtexten und Seed-Projekten organisch zur Unterstützung von progressiven Web-Apps als Kernfunktion werden wird. Bis dahin ist der Aufwand, diese Funktionen in Ihre eigenen Apps einzubinden, nicht sehr hoch und meiner Meinung nach durchaus lohnenswert.
Architektur
Es gibt verschiedene Stufen der Nutzung des Progressive Web App-Modells. Ein gängiger Ansatz besteht darin, sie um eine Anwendungs-Shell herum zu entwickeln. Dies ist keine zwingende Voraussetzung, hat aber einige Vorteile.
Die Anwendungs-Shell-Architektur empfiehlt, die Anwendungs-Shell (Benutzeroberfläche) zu cachen, damit sie offline funktioniert, und die Inhalte mit JavaScript zu füllen. Bei wiederholten Besuchen können Sie so ohne Netzwerk sehr schnell relevante Pixel auf dem Bildschirm anzeigen, auch wenn Ihre Inhalte letztendlich von dort stammen. Das führt zu erheblichen Leistungssteigerungen.
Jeremy Keith bemerkte vor Kurzem, dass bei diesem Modell das serverseitige Rendering nicht als Fallback, sondern das clientseitige Rendering als Verbesserung betrachtet werden sollte. Das ist ein berechtigtes Feedback.
Im Application Shell-Modell sollte so oft wie möglich serverseitiges Rendering verwendet werden. Das clientseitige progressive Rendering sollte als Erweiterung genutzt werden, so wie wir die Erfahrung „verbessern“, wenn Service Worker unterstützt wird. Es gibt viele Möglichkeiten, dies zu erreichen.
Ich empfehle Ihnen, unseren Artikel zur Architektur zu lesen und zu überlegen, wie ähnliche Prinzipien am besten auf Ihre eigene Anwendung und Ihren eigenen Stack angewendet werden können.
Erste Schritte mit Textbausteinen
Anwendungs-Shell
Das app-shell
-Repository enthält eine nahezu vollständige Implementierung der Application Shell-Architektur. Es hat ein in Express.js geschriebenes Backend und ein in ES2015 geschriebenes Frontend.
Da es sowohl client- als auch serverseitige Teile des Modells abdeckt und dort ziemlich viel los ist, wird es einige Zeit dauern, bis Sie sich mit der Codebasis vertraut gemacht haben. Es ist derzeit unser umfassendster Ausgangspunkt für progressive Web-Apps. Im nächsten Schritt werden wir uns bei diesem Projekt auf Docs konzentrieren.
Starterkit aus Polymer
Der offizielle Ausgangspunkt für Polymer-Web-Apps unterstützt die folgenden Funktionen von progressiven Web-Apps:
- Manifest der Webanwendung
- Chrome für Android-Startbildschirm
- Offline-Caching von Service Workers mit den Platinum-SW-Elementen
- Push-Benachrichtigungen (manuelle Einrichtung erforderlich) mit den Platin-Push-Elementen
Die aktuelle Version des PSK unterstützt einige der erweiterten Leistungsmuster (z. B. Application Shell-Modell, asynchrones Laden), die in einigen Progressive Polymer-Web-Apps zu finden sind.
Wir versuchen, diese Muster 2016 in PSK zu integrieren, aber erste Experimente zu diesem Thema finden Sie in der Polymer App Zuperkulblog von Rob Dodson und im hervorragenden Vortrag zu Polymer Perf Patterns von Eric Bidelman.
Web-Starterkit
Unser persönlicher Ausgangspunkt für neue Vanilla-Projekte umfasst die folgenden Funktionen für progressive Web-Apps:
- Manifest der Webanwendung
- Chrome für Android-Startbildschirm
- Service Worker-Pre-Caching 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, aus der Sie Code-Snippets wiederverwenden oder stehlen können.
Progressive Web-Apps mit und ohne Frameworks
Eine Reihe von progressiven Open-Source-Web-Apps wurden bereits von Mitgliedern der Community mit und ohne JS-Bibliotheken und -Frameworks entwickelt. Wenn Sie nach Inspiration suchen, können die folgenden Repos als Referenz dienen. Außerdem sind es einfach verdammt gute Apps.
Vanilla JavaScript
- Voice Memos von Paul Lewis basiert auf einer ähnlichen Architektur wie
app-shell
(write-up) - Offline Wikipedia von Jake Archibald (Video)
- Air Horner von Paul Kinlan
- Guitar Tuner von Paul Lewis (Artikel)
Polymer
- Zuperkulblog von Rob Dodson (Folien)
React
Virtual-DOM
- Pokedex von Nolan Lawson: Eine hervorragende progressive Web-App, die den Ansatz „alles in einem Webworker erledigen“ verfolgt, um das progressive Rendering zu unterstützen. (Zusammenfassung)
Angular.js
- Timey.in von Kenneth Auchenberg – verwendet auch
sw-precache
für das Ressourcen-Precaching
Abschließende Notizen
Wie bereits erwähnt, befinden sich progressive Web-Apps noch in der Entwicklungsphase. Es ist jedoch eine spannende Zeit, um mit den zugrunde liegenden Methoden zu experimentieren und zu sehen, wie gut sie auf Ihre eigenen Web-Apps angewendet werden können.
Paul Kinlan plant derzeit die Web Fundamentals-Leitfäden zu Progressive Web Apps. Wenn Sie Vorschläge zu Themen haben, die behandelt werden sollten, können Sie diese gerne in diesem Thread kommentieren.
Weitere Informationen
- Progressive Web-Apps: Tabs vermeiden, ohne die Seele zu verlieren
- Warum progressive Web-Apps die Zukunft der Webentwicklung sind
- Progressive Web-Apps: bereit für die Primetime
- Mit ServiceWorker progressive Apps entwickeln
- Progressive Web-Apps sind die Zukunft
- Progressive Web-App: Eine neue Art der mobilen Nutzung
- Wir stellen vor: Pokedex.org – eine progressive Web-App für Pokémon-Fans
- Chrome Developer Summit – Zusammenfassung: Progressive Web-Apps