Progressive Web Apps sind in aller Munde. Sie stellen die nächste Evolutionsstufe des Webs dar und vereinen die Vorteile von Webseiten mit denen von nativen und hybriden Apps. In diesem Artikel nutzen wir das leistungsfähige Framework React, um eine Progressive Web App zu erstellen.
Steve Jobs war seiner Zeit weit voraus. Als er vor zehn Jahren, im Jahr 2007, das erste iPhone vorstellte, hatte er eine Vision, wie Apps funktionieren sollen. Nach seiner Vorstellung sollten Web-Apps komplett im Safari-Browser laufen und per JavaScript und Ajax das Verhalten von nativen Apps imitieren. Der Plan ging jedoch nicht auf. Das erste iPhone war für Web-Apps zu langsam, viele Schnittstellen zur Hardware fehlten, und die User Experience war den nativen Apps massiv unterlegen. Entwickler fühlten sich von Apple bevormundet und forderten die Möglichkeit, native Apps zu schreiben. Mit den daraus resultierenden App Stores entstand ein Markt mit milliardenschweren Umsätzen. Zehn Jahre später sind Apps ein fester Bestandteil von iOS, Android und Windows Phone. Dennoch gibt es einen Trend, der die Idee der ursprünglichen Web-Apps aufgreift und in ein modernes Gewand packt.
Viele Gründe, die Web-Apps vor zehn Jahren scheitern ließen, sind heute nicht mehr aktuell. Smartphones haben heutzutage die Rechenleistung von Desktopcomputern, und Standards wie HTML5, CSS3 und JavaScript haben sich deutlich weiterentwickelt. Im Jahr 2015 prägte Google den Begriff Progressive Web Apps (PWAs). PWAs sind Webanwendungen, die sich wie Apps anfühlen, aber über den Browser und ohne den Umweg über die App-Store-Installation aufgerufen werden können. Google hat genaue Vorstellungen, was eine Webseite zur Progressive Web App macht. PWAs sollen sich für Nutzer wie native Apps anfühlen: Sofortiges Laden von Inhalten ohne spürbare Verzögerung, Offlinefähigkeit und die Möglichkeit, die App auf dem Homescreen zu installieren. Es geht sogar noch weiter. Progressive bedeutet in diesem Kontext, dass eine grundlegende Version der Seite auch auf Browsern funktioniert, die nicht die modernsten Standards unterstützen. Somit schließen PWAs die Lücke zwischen nativen Apps und mobilen Seiten. Für ältere Browser wird die Seite zumindest rudimentär angezeigt. Unterstützt ein Browser alle notwendigen Features, wird dem Nutzer ein App-ähnliches Erlebnis geboten. Um dieses Ziel umzusetzen, sind einige neue Konzepte notwendig, die im Folgenden besprochen werden.
Service Worker sind lichtscheu. Als Nutzer einer Web-App hat man normalerweise keinen direkten Kontakt zu ihnen. Dennoch sind sie ein wichtiger Teil der Magie, die dafür sorgt, dass eine PWA offlinefähig ist oder Notifications anzeigen kann. Um Service Worker weiter zu entzaubern: Sie sind schlichtweg JavaScript-Programme, die im Browser laufen.
Argwöhnische Leser mögen nun fragen, wie sich Service Worker von normalen Skripten auf Webseiten unterscheiden. Der größte Unterschied liegt im Kontext der Service Worker: Es handelt sich um globale Skripte, die nicht an eine bestimmte Seite gebunden sind. Sie gelten generell für einen gesamten Ressourcenpfad einer Domain und können auch ohne eine Webseite ausgeführt werden. Durch den globalen Skriptkontext haben sie zudem keinen Zugriff auf das DOM (Document Object Model) der jeweiligen Seiten. Ganz bildlich kann man sich Service Worker als Schnittstelle zwischen der Webseite und dem Internet vorstellen. Derzeit spielen vor allem die drei folgenden Aspekte eine besondere Rolle.
Service Worker können Ressourcenaufrufe der jeweiligen Seite übernehmen und durch gecachte oder modifizierte Responses ersetzen. Dem sicherheitsorientierten Leser mag es beim Gedanken an durch Dritte modifizierte Responses nun kalt den Rücken hinunterlaufen. Doch keine Sorge, um Service Worker einzusetzen, ist HTTPS Pflicht, um eventuelle Man-in-the-Middle-Angriffe zu verhindern.
Stellen Sie sich folgende Situation vor: Sie nutzen den Webmailclient ihres E-Mail-Anbieters und tippen auf dem Smartphone eine lange E-Mail. Just in dem Moment, in dem Sie auf Absenden drücken, verliert Ihr Smartphone die Mobilfunkverbindung und sowohl Ihre eingegebene E-Mail als auch Ihre gute Laune sind verschwunden. Mit einer Background-Sync-Implementierung wäre das nicht passiert. Background-Sync erlaubt es, Aktionen dann auszuführen, wenn das Netzwerk verfügbar ist. Das funktioniert sogar, wenn der Browser-Tab geschlossen oder der Anwender längst zu einer anderen Seite navigiert ist.
Wird eine Webseite gerade nicht im Smartphonebrowser angezeigt, kann sie nicht mit dem Nutzer interagieren. Diese einfache wie offensichtliche Erkenntnis führt dazu, dass für Hinweismeldungen ein globaler Skriptkontext notwendig ist. Genau den bieten Service Worker. Mit dem Notifications-API ist es möglich, dem Anwender sowohl auf dem Desktopbrowser als auch auf dem Smartphone Benachrichtigungen anzuzeigen.
Um den Entwicklern das Leben zu erleichtern und die Qualität von PWAs insgesamt zu steigern, bietet Google mit Lighthouse ein Open-Source-Werkzeug an, mit dem man eine Webseite auf Herz und Nieren hinsichtlich der Anforderungen von PWAs prüfen kann. Lighthouse ist als Chrome ...