Faktencheck zu Progressive Web Apps, Teil 3: Offenheit und Abwärtskompatibilität

Im vergangenen Teil dieser Serie ging es um die Privatsphäre und Sicherheit zeitgemäßer Webschnittstellen. Zahlreiche neue Webschnittstellen sollen Progressive Web Apps mit noch mehr Features ausstatten. In diesem Teil bespreche ich die Offenheit und Abwärtskompatibilität dieser APIs.

Google treibt das Anwendungsmodell der Progressive Web Apps nach wie vor stark voran. Im Rahmen des Google-Projekts Fugu sollen weitere mächtige Webschnittstellen in Google Chrome Einzug erhalten, darunter die Badging API (Anzeige eines Notification-Badges auf dem App-Symbol), die Writeable Files API (Zugriff auf einen Teilbereich des Dateisystems) oder die Wake Lock API (automatische Bildschirmsperre deaktivieren).

Sind moderne Webschnittstellen ausschließlich Google Chrome vorbehalten?

Befürchtungen, dass die oben genannten Schnittstellen allein Chrome vorbehalten wären, sind unbegründet. Diese werden allesamt offen standardisiert, wie auch die PWA-Schnittstellen Service Worker und Web App Manifest. Zuletzt fand etwa die Web Share API zum Teilen von Webinhalten ihren Weg in die Vorschauversion von Apple Safari. Und die PWA-Basisschnittstellen werden schon seit längerer Zeit von allen vier großen Webbrowsern implementiert.

Im Falle der drei oben genannten APIs findet die Spezifikation bei der Web Platform Incubator Community Group (WICG) des World Wide Web Consortium (W3C) statt. Diese Spezifikationen sind frei verfügbar und können von jedem Browserhersteller ohne Entgelt implementiert werden. Eine der Bedingungen für das Zustandekommen moderner Webschnittstellen ist im Übrigen sogar, dass ein Interesse seitens verschiedener Browserhersteller besteht, diese auch in ihrem Webbrowsern umzusetzen.

Die Spezifikationen werden außerdem nicht im stillen Kämmerlein entwickelt: Entwickler können sich über Pull-Requests an der Spezifikation von Webschnittstellen beteiligen, je nach Standardisierungsorganisation und Arbeitsgruppe in mehr oder weniger begrenztem Umfang.

Was bedeuten Progressive Web Apps für die Abwärtskompatibilität im Web?

Das Web weist seit jeher eine abwärtskompatible Natur auf. Ein HTML-Dokument aus der Anfangszeit des World Wide Web können auch heutige Webbrowser noch problemlos darstellen. Neu eingeführte Funktionen dürfen das Web also nicht brechen, sondern müssen sich abwärtskompatibel verhalten. Das geht sogar soweit, sodass die JavaScript-Funktion zur Prüfung, ob ein Element in einem Array vorhanden ist, von contains() nach includes() umbenannt wurde, da die Funktion contains() bereits von der seinerzeit recht weit verbreiteten Bibliothek MooTools belegt wurde. Daher dürfen neue Webschnittstellen immer nur ein zusätzliches Extra sein.

Die PWA-Basistechnologien Service Worker und Web App Manifest verhalten sich genau so. Progressive Web Apps definieren einen Anforderungskatalog an Webanwendungen, die sich PWA nennen wollen. Eine dieser Anforderungen heißt: Progressive. Eine PWA soll in Grundzügen auch in älteren Webbrowsern wie dem Internet Explorer 11 funktionieren, selbst wenn dieser Webbrowser die Basistechnologien Service Worker und Web App Manifest nie unterstützen wird. Dazu wird das Prinzip der Feature Detection eingesetzt: Es wird zuerst geprüft, ob eine Webschnittstelle verfügbar ist, bevor sie verwendet wird. Damit funktioniert die Anwendung auch noch auf älteren Browsern, umgekehrt erhalten Nutzer moderner Webbrowser komfortable Zusatzfeatures. Dieses Prinzip nennt man Progressive Enhancement als Umkehr der Graceful Degradation.

Bei Spezifikationen wird darauf geachtet, dass zukünftige Funktionalität ebenfalls in einer abwärtskompatiblen Weise implementiert werden kann. Manchmal werden Schnittstellen aus der Web-Plattform auch wieder entfernt, etwa die Methode document.registerElement() aus dem Web-Components-Umfeld. Dies ist jedoch ein mehrjähriger Prozess, dem eine Deprecation-Phase vorausgeht.

Progressive Web Apps haben auch Grenzen, die ich im kommenden Teil dieser Serie thematisieren möchte. Wie diese aufgeweicht werden können, bespreche ich nächste Woche. ()