Mächtigeres Web dank Kugelfisch

Wie Project Fugu PWAs noch besser macht

Christian Liebel

©Shutterstock / FtLaud

2015 wurde der Begriff der Progressive Web App (PWA) geprägt. Seit etwa 2018 können PWAs auf allen relevanten Betriebssystemen installiert und auch offline ausgeführt werden. Allerdings bleibt hinsichtlich der Funktionalität ein gewisser Unterschied zwischen PWAs und ihren nativen Gegenstücken bestehen. Mit Project Fugu soll der Abstand weiter schrumpfen.

Als Steve Jobs 2007 das iPhone vorstellte, war weder von Apps noch vom App Store die Rede. Stattdessen sollten Entwickler Webanwendungen auf Basis von HTML schreiben, um Drittanbieteranwendungen auf das neue Smartphone zu bringen. Die Vorteile liegen auf der Hand: Webanwendungen sind plattformübergreifend ausführbar, laufen in einer Sandbox und haben keinen wahlfreien Zugriff auf native Schnittstellen. Wohl nicht zuletzt aufgrund der letzten beiden Punkte liebäugelte Jobs mit dem Web als Anwendungsplattform. Doch die geringe Performance durch die anfangs schwache Hardware und die nicht gerade ausgeprägten Fähigkeiten im Web führten am Ende dazu, dass Apple seine Meinung änderte und später doch ein Software Development Kit (SDK) zur nativen Entwicklung anbot.

Im Web ist seitdem jedoch viel passiert: Moderne JavaScript und WebAssembly Engines erreichen eine nahezu native Performance und CSS3-Animationen laufen absolut ruckelfrei. HTML5 brachte jede Menge Schnittstellen ins Web, unter anderem lokale Speichertechnologien und den Zugriff auf den Standort des Anwenders. WebGL brachte hardwarebeschleunigte 3D-Visualisierungen, WebRTC Peer-to-Peer-basierte Echtzeitkommunikation. Dann kamen Progressive Web Apps, die mit Hilfe von Service Workers offline ausgeführt werden können und dank dem Web-App-Manifest auch eine Präsenz auf dem Homescreen oder in der Programmliste des jeweiligen Betriebssystems erhalten. Von dort gestartet ist die PWA von nativen Anwendungen kaum mehr zu unterscheiden. Abbildung 1 zeigt die Progressive Web App von Spotify, die ihrem nativen Gegenstück sehr stark ähnelt. All diese Funktionen hätte man dem Web noch vor wenigen Jahren gar nicht zugetraut. Doch trotz aller Anstrengungen bleibt eine gewisse Lücke zwischen Webanwendungen und nativen Apps bis heute bestehen.

Abb. 1: Spotify als Progressive Web App: kaum ein Unterschied zum nativen Client

Abb. 1: Spotify als Progressive Web App: kaum ein Unterschied zum nativen Client

Mission: ein leistungsfähigeres Web

Die drei Chromium-Beitragenden Google, Microsoft und Intel wollen diese Situation nun ändern und haben sich hierfür zum Web Capabilities Project, besser bekannt unter dem Codenamen Project Fugu, zusammengeschlossen. Das Ziel des Projektes ist es, fehlende Features, die Entwickler heute noch davon abhalten könnten, ihre Anwendung als Weblösung zu implementieren, im Web bereitzustellen. Project Fugu APIs sollen, sofern sinnvoll, plattformübergreifend eingesetzt werden können. Insbesondere sollen keine Plattformunterscheidungen erforderlich sein, wie man sie von anderen Cross-Plattform-Ansätzen kennt. Stattdessen muss sich der Webbrowser darum kümmern, die richtige native Schnittstelle aufzurufen. Alle drei Unternehmen haben ein Interesse an mächtigen Webanwendungen: Auf dem quelloffenen Browserunterbau Chromium basieren Googles eigener Webbrowser Chrome und das Betriebssystem Chrome OS, für das sich Progressive Web Apps natürlich hervorragend eignen. Microsoft gab zuletzt die Implementierung einer eigenen Browser-Engine auf, die neue Version von Microsoft Edge basiert ebenfalls auf Chromium. Da der eigene Anwendungsmarktplatz Microsoft Store nie wirklich Fahrt aufgenommen hat, freut man sich über die zusätzliche Anwendungsvielfalt, die Progressive Web Apps bringen. Intel hingegen vertreibt Hardware, und die Nachfrage durch ein stärkeres Web würde gleich auf zwei Seiten steigen: bei Clients und Servern.

Heute sind Entwickler in vielen Fällen dazu gezwungen, Anwendungen nativ zu entwickeln oder auf Wrapper-Ansätze wie Apache Cordova oder GitHubs Electron zurückzugreifen. Diese Projekte verpacken eine Webanwendung in einem nativen Anwendungsrahmen für Mobilgeräte (Cordova) oder Desktopsysteme (Electron). Über diesen nativen Anwendungsrahmen kann die Webanwendung dann auf sämtliche Schnittstellen zugreifen, die auch nativen Anwendungen zur Verfügung stehen. Die APIs werden der Webanwendung dann in Form von JavaScript-Schnittstellen angeboten. Umgekehrt setzen diese Ansätze aber auch ein Deployment der Anwendung über den jeweiligen App-Store (iOS, macOS, Android) oder eine ausführbare Datei (Windows, macOS, Linux) voraus. Für Stores ist oftmals eine kostenpflichtige Mitgliedschaft erforderlich, Apps müssen darüber hinaus bestimmte Kriterien erfüllen. Entwickler sind hier vom guten Willen des Storeanbieters abhängig. Im Falle von GitHub Electron liegen der Anwendung außerdem nicht nur die HTML-, CSS- und JS-Quelldateien bei, sondern auch eine Kopie der Node.js Runtime, über die native Funktionen aufgerufen werden, und Chromium für die Darstellung der Webanwendung. Diese Abhängigkeiten sind nicht nur relativ groß, sodass selbst eine Hello-World-Anwendung schon mehrere Dutzend Megabyte benötigt. Auch führen die zusätzlichen Browser- und Node-Prozesse zu einem Overhead in der Nutzung des Arbeitsspeichers. Vor allem aber läuft die Anwendung nicht mehr ohne Installation im Browser.

Durch Project Fugu könnten native Wrapper bald der Vergangenheit angehören. Funktionen, die bisher den Einsatz von Anwendungsrahmen erfordert haben, sollen künftig direkt im Browser verfügbar sein. So ist im Rahmen von Project Fugu etwa die Einführung des Native File System API geplant, das dem Entwickler Zugriff auf das native Dateisystem gewähren soll. Diese Schnittstelle kann gleich ganze Anwendungskategorien ins Web bringen, die bisher auf Electron oder Cordova angewiesen waren: Bild- oder Videobearbeitungsprogramme, Büroanwendungen und Produktivitäts-Apps.

Dabei muss natürlich immer auch die Sicherheit und Privatsphäre der Anwender bedacht werden. Denn nicht nur Webanwendungen erhalten Zugriff auf die Schnittstellen, sondern auch Werbetreibende und Anbieter potenziell schädlicher Websites. Das Native File System API erlaubt daher nur einen beschränkten Zugriff. So können etwa keine Systemverzeichnisse ausgelesen oder manipuliert werden. Schreibende Zugriffe setzen eine Zustimmung des Anwenders voraus. Dazu passend sollen sich Anwendungen auch als File-Handler für eine bestimmte Dateierweiterung registrieren können. Beim Doppelklick auf eine Datei mit dieser Erweiterung öffnet sich künftig die dafür hinterlegte Webanwendung. Ebenfalls nützlich für Produktivitätsanwendungen ist das Raw Clipboard Access API, das Entwicklern einen tiefgreifenden Zugriff auf die Zwischenablage einräumen soll. Damit sollen Anwendungen künftig mit beliebigen Formaten in der Zwischenablage umgehen können. Aktuell ist das nur für Text und in manchen Browsern für Bilddaten möglich.

Darüber hinaus sind viele weitere Schnittstellen geplant, etwa das Badging API, um ein Benachrichtigungs-Badge auf dem Icon einer installierten PWA darzustellen, vergleichbar zu E-Mail-Anwendungen oder Messengerdiensten. Auch das Anwendungsmenü sollen PWAs künftig anpassen können, unter macOS sollen Entwickler auch Einfluss auf die in der Touch Bar dargestellten Werkzeuge nehmen können. Die komplette Liste aller Schnittstellen ist nach Priorisierung sortiert im Fugu API Tracker [1] in Abbildung 2 zu sehen. Weiterhin ist der Implementierungsfortschritt der jeweiligen Schnittstellen zu sehen. Um auf dem aktuellsten Stand zu bleiben, können Entwickler sich für Benachrichtigungen bei Änderungen des Dokumentes registrieren.

Abb. 2: Im Fugu API Tracker sind alle geplanten Schnittstellen aufgeführt

Abb. 2: Im Fugu API Tracker sind alle geplanten Schnittstellen aufgeführt

So entstehen Fugu-Schnittstellen

Ideen für Schnittstellen kommen meist von den an Fugu beteiligten Unternehmen oder ihren Partnern, grundsätzlich kann aber jeder unter [2] Vorschläge einreichen. Das Fugu-Team sichtet die Vorschläge, ermittelt den Bedarf und ordnet dem Vorschlag eine Priorität zu. In einem sogenannten Explainer wird die Idee zunächst grob umrissen. Das Problem wird erklärt, mögliche Auswirkungen auf die Sicherheit und Privatsphäre der Anwender untersucht, der Stand der Technik beschrieben und die angedachte Schnittstelle skizziert. Dann wird bei Webentwicklern und den übrigen Browserherstellern – vorrangig Mozilla und Apple – Feedback eingeholt und auf Basis dessen ein Schnittstellenentwurf ausgearbeitet. Dieser wird auch direkt auf den Standardisierungsweg gebracht. Sobald der Entwurf stabil erscheint, wird die Schnittstelle direkt in Chromium implementiert. Dort ist sie zunächst hinter einem Browser-Flag verfügbar, später kann sie im Zuge einer Versuchsphase (Origin Trial) auf einzelnen Websites (Origins) für ein begrenztes Publikum erprobt werden – ohne dass die Anwender das Flag aktivieren müssen. Dieses Vorgehen soll insgesamt dazu führen, dass ein Konsens zwischen den Browserherstellern erreicht wird. Ist das nicht der Fall, besteht die Gefahr, dass die Schnittstelle nur in Chromium-basierten Browsern wie Google Chrome, Microsoft Edge, Opera und Samsung Internet zur Verfügung steht.

Web Share API: Teilen von Inhalten über das Web

Das Web Share API ist ein gutes Beispiel für eine Schnittstelle, bei der das Fugu-Konzept geglückt ist. Mit Hilfe dieses API können Inhalte über den nativen Teilen-Dialog des Betriebssystems mit anderen installierten Anwendungen geteilt werden. Die Schnittstelle funktioniert plattformübergreifend auf Mobil- und Desktopgeräten und wird auch von fremden Browserherstellern implementiert – auf dem Desktop als erstes sogar von Apple, die sich sonst eher zurückhaltend bei der Bereitstellung neuer Webschnittstellen mit nativer Power zeigen. In Listing 1 ist ein Beispiel für die Verwendung des APIs zu sehen.

Das Web Share API erweist sich in der Handhabung als besonders einfach. Technisch gesehen handelt es sich bei diesem API um eine Erweiterung der Navigator-Schnittstelle in JavaScript, die webbrowserbezogene Informationen und Aktionen verfügbar macht. Zum Teilen von Inhalten wird auf dem navigator-Objekt die Methode share() bereitgestellt. Sie nimmt ein Konfigurationsobjekt entgegen, dem ein zu teilender Text (text), eine URL (url) oder ein Titel (title) übergeben werden können. Sämtliche Eigenschaften sind optional, mindestens eine Angabe muss im Objekt jedoch gemacht werden. Daraufhin wird der native Teilen-Dialog mit allen Anwendungen dargestellt, die die jeweilige Information entgegennehmen können. Die share()-Methode gibt ein Promise zurück. Wurde der Inhalt erfolgreich mit einer anderen Anwendung geteilt, wird das Promise aufgelöst. In allen anderen Fällen wird es zurückgewiesen, etwa wenn keine Anwendung den zu teilenden Inhalt entgegennehmen kann oder der Anwender den Vorgang abbricht. Abbildung 3 zeigt die Verwendung des Web Share API unter Safari auf macOS: Beim Klick auf die im Bild oben dargestellte Schaltfläche wird die shareUrl()-Methode aus Listing 1 aufgerufen. Der angegebene URL kann auf diesem System über die Messages-App, AirDrop oder die Notizen-App sowie an den Simulator oder die Erinnerungen-App geteilt werden. Unten ist der Teilen-Dialog der Messages-App zu sehen. Oben werden die Kontakte angegeben, an die die Nachricht geschickt werden soll. Die Nachricht ist mit dem Text und dem URL vorbefüllt, der Titel passt hier nicht und wurde daher verworfen. Auf Wunsch kann der Anwender die Nachricht noch einmal anpassen. Schließlich kann die Nachricht entweder verschickt oder der Vorgang abgebrochen werden. Auf Mobilgeräten mit iOS und Android funktioniert die Schnittstelle auf die exakt gleiche Weise – Entwickler müssen also keine Änderung entsprechend der Plattform vornehmen.

Abb. 3: Funktionsweise des Web Share API in Safari

Abb. 3: Funktionsweise des Web Share API in Safari

Im Listing ist weiterhin das Konzept des Progressive Enhancement zu sehen: Hierbei sollen Entwickler das Vorhandensein einer Schnittstelle prüfen. Dazu dient die Verzweigung um den gezeigten Code. Steht das Web Share API auf einem System nicht zur Verfügung, sollte kein Fehler auftreten. Das würde passieren, wenn auf einem System ohne Unterstützung für diese Schnittstelle versucht wird, die oben gezeigte Methode aufzurufen. Ist das API nicht verfügbar, könnte die Funktion in der Benutzeroberfläche entweder ausgeblendet oder auf eine Fallback-Implementierung zurückgegriffen werden. So könnte etwa über das mailto:-Pseudoprotokoll die E-Mail-App des Anwenders geöffnet werden.

Um zu vermeiden, dass aufdringliche Werbeanzeigen und schädliche Websites ohne Zutun des Anwenders eine Aufforderung zum Teilen von Inhalten anzeigen, lässt sich die Schnittstelle nur infolge einer Benutzerinteraktion, etwa einem Mausklick oder einem Tastendruck aufrufen. Weiterhin kann sie nur genutzt werden, wenn die Website über das Hypertext Transfer Protocol Secure (HTTPS) übertragen wurde. Diese Voraussetzung gilt inzwischen für so gut wie alle Webschnittstellen, die Zugriff auf native Funktionen erlauben.

Das Web Share API steht in Google Chrome auf Android seit Version 61 zur Verfügung, unter macOS ab Safari 12.1 sowie unter iOS ab Version 13.0 (Safari 12.2). In diesem Jahr sollen die Implementierungen in der Desktopversion von Google Chrome sowie in Mozilla Firefox folgen.

Der zweite Entwurf der Schnittstelle erlaubt darüber hinaus das Teilen von Dateien über die zusätzliche Eigenschaft files. Mithilfe des Web Share Target API können sich Progressive Web Apps auch als Ziel für eine Teilen-Operation registrieren. Beide Features sind im Rahmen von Project Fugu entstanden und laufen derzeit nur unter Chromium.

Fahrplan für Webentwickler

Webentwickler sollten danach streben, ihre Anwendung als Progressive Web App zu implementieren, also als reine Weblösung. Nur wenn eine bestimmte Funktion im Web nicht zur Verfügung steht, sollten Entwickler zusätzlich oder stattdessen auf Wrapper-Lösungen zurückgreifen. Das ist auch dann der Fall, wenn Entwickler zwingend eine Präsenz im iOS-App-Store oder eine ausführbar Datei benötigen. Die Investition in eine Webanwendung macht sich letztlich immer bezahlt. Cordova und Electron sollten als eine Art Polyfill angesehen werden, die für eine Übergangszeit Funktionen zur Verfügung stellen, die es im Web heute noch nicht gibt. Sobald die jeweilige Funktion direkt im Web bereitgestellt wird, kann der Wrapper entfallen.

Wenn Entwickler im Web an eine Grenze stoßen, sollten sie den gewünschten Anwendungsfall und die fehlende Schnittstelle an die Browserhersteller melden, etwa über den oben genannten Link an das Fugu-Team oder die Bugtracker der jeweiligen Engines.

Fazit: gute Aussichten für Webentwickler

Project Fugu tritt an, um Progressive Web Apps noch besser zu machen. Fähigkeiten, die heute noch native Anwendungen oder Wrapper wie Cordova oder Electron voraussetzen, könnten in Zukunft direkt im Browser bereitgestellt werden. Die Liste der geplanten Fähigkeiten verheißt ungeahnte Möglichkeiten für Webanwendungen – für Webentwickler sind das auch weiterhin beste Aussichten.

Verwandte Themen:

Geschrieben von
Christian Liebel
Christian Liebel
Christian Liebel ist Softwareentwickler bei der Thinktecture AG in Karlsruhe. Dort entwickelt er moderne Cross-Plattform-Apps auf Basis von Angular, Cordova, Electron, Node.js und .NET. Er ist mit dem Web groß geworden und hat sein Handwerk mit Microsoft-Technologien gelernt. Er ist begeistert von den neuen Möglichkeiten der Anwendungsentwicklung, die sich mit HTML5, JavaScript, TypeScript und Angular erschließen.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: