Was ist Project Fugu?
Google, Microsoft und Intel haben sich zum Web Capabilities Project, besser bekannt unter dem Codenamen Project Fugu zusammengeschlossen, um die Lücke zwischen Web-Apps und nativen Anwendungen zu schließen. Dazu werden im Web neue Programmierschnittstellen mit nativer Power eingeführt. Die drei beteiligten Unternehmen tragen zur Weiterentwicklung des quelloffenen Browserunterbaus Chromium bei, auf dem etwa die Browser Google Chrome, Samsung Internet, Opera oder die neue Fassung von Microsoft Edge basieren. Die geplanten APIs schließen neben vielen weiteren einen umfassenden Zugriff auf das Dateisystem (File System Access API) oder die Zwischenablage (Raw Clipboard API) mit ein:
Schnittstelle Fähigkeit
File System Access API | Erlaubt Zugriff auf Teilbereiche des nativen Dateisystems (ohne sensible oder Systemverzeichnisse). | |
Raw Clipboard Access API | Gewährt umfassenden Zugriff auf die Zwischenablage des Systems. | |
Wake Lock API | Verhindert das Abschalten des Bildschirms für Kioskanwendungen, Rezepteapps und ähnliches. | |
Screen Enumeration API | Zählt die verbundenen Bildschirme auf, sinnvoll in Kombination mit der Window Placement API. | |
Window Placement API | Erlaubt die Platzierung von Fenstern an einer bestimmten Position auf einem angegeben Bildschirm, etwa für Multi-Window- oder Multi-Monitor-Anwendungen. |
Eine Auswahl von Fugu-Schnittstellen.
Ganze Anwendungskategorien, die bisher nativ entwickelt oder in einem nativen Wrapper verpackt werden mussten, sollen damit den Weg ins Web finden: etwa Bild- und Videoeditoren, Produktivitätsanwendungen wie Office-Programme oder integrierte Entwicklungsumgebungen. Die komplette Liste der geplanten Schnittstellen ist inklusive Implementierungsfortschritt im Fugu API Tracker zu finden. Das Fugu-Team holt für alle APIs Feedback bei Webentwicklern, Standardisierungsgremien und übrigen Browserherstellern ein und bringt die Schnittstellen auf den Standardisierungsweg.
Project-Fugu-APIs abstrahieren Plattformunterschiede: Der Browser ruft die jeweils korrekte API auf dem Zielbetriebssystem auf.
Die durch Fugu bereitgestellten Schnittstellen sind in der Regel plattformübergreifend einsetzbar, Entwickler rufen also auf allen Systemen ein- und dieselbe Schnittstelle auf. Insbesondere muss nicht, wie es bei anderen Cross-Platform-Ansätzen teilweise üblich ist, je nach Plattform eine andere API aufgerufen werden. Stattdessen kümmert sich der Webbrowser darum, dass auf dem Zielsystem die jeweils passende native Schnittstelle aufgerufen wird. In die Zuständigkeit des Entwicklers fällt jedoch, zur Laufzeit zu prüfen, ob die gewünschte Schnittstelle vorhanden ist. Das ist erforderlich, damit Anwendungen in Browsern ohne Unterstützung für die API nicht in einen Fehlerzustand übergehen (Progressive Enhancement). Am Beispiel der Web Share API, die das Teilen von Inhalten über den nativen Share-Dialog erlaubt, sieht das wie folgt aus:
document.querySelector('#share-button').addEventListener('click', () => {
if ('share' in navigator) {
navigator.share({ text: 'Hallo Welt' });
} else {
window.open('mailto:?body=Hallo%20Welt');
}
});
In der Verzweigung wird geprüft, ob die gewünschte Schnittstelle navigator.share() zur Verfügung steht. Ist die API vorhanden, wird sie aufgerufen und der dargestellte Text Hallo Welt mit einer kompatiblen Anwendung geteilt. Andernfalls kann entweder die Funktionalität in der App versteckt oder, sofern verfügbar, auf eine Fallback-Implementierung zurückgegriffen werden. Im obigen Beispiel würde über das mailto-Pseudoprotokoll stattdessen das Standard-E-Mail-Programm mit dem angegebenen Text geöffnet.
Wie macht Project Fugu Progressive Web Apps noch besser?
Progressive Web Apps (PWA) können dank dem Service Worker auf allen relevanten Mobil- und Desktopplattformen offline ausgeführt werden. Dazu werden die HTML-, JS- und CSS-Quelldateien der Anwendung im Cache des Service Workers abgelegt, von dort startet die App besonders schnell und eben auch bei fehlender Internetverbindung.
Die Anwendungsquelldateien werden bei Progressive Web Apps im Service-Worker-Cache hinterlegt und sind damit auch offline verfügbar.
Das Leben einer PWA beginnt im Browser, dank des Web App Manifests kann sie zum schnelleren Zugriff auf den Homebildschirm oder in der Programmliste des Zielbetriebssystems eine Verknüpfung erhalten. Von dort aus gestartet kann die Anwendung etwa im Standalone-Modus ausgeführt werden und ist optisch von nativen Anwendungen dann nicht mehr zu unterscheiden. Allerdings können PWA nur auf Funktionen zugreifen, für die es auch eine offizielle Webschnittstelle gibt. Einen guten Eindruck über die im Web zur Verfügung stehenden Fähigkeiten vermittelt die Website whatwebcando.today. Im modernen Web ist vieles möglich, etwa 3-D-Visualisierungen, die Speicherung strukturierter Daten in einer lokalen Clientdatenbank oder Videokommunikation in Echtzeit, aber eben noch nicht alles. Project Fugu möchte die Lücke zwischen nativen Anwendungen und Progressive Web Apps durch eine Vielzahl neuer Fähigkeiten und Schnittstellen schließen.
Bei Electron und Cordova werden die Anwendungsquelldateien in einem nativen Bündel ausgeliefert.
Um auf solche Features aus Webanwendungen heraus zuzugreifen, bedarf es aktuell in vielen Fällen noch nativen Wrappern wie Apache Cordova oder GitHub Electron. Bekannte Anwendungen wie Visual Studio Code, Atom, Skype oder Slack greifen auf solche Ansätze zurück. Die HTML-, JavaScript- und CSS-Quelldateien einer Web-App werden dabei in einem nativen Anwendungsrahmen verpackt, über den jede beliebige native Schnittstelle aufgerufen werden kann. Damit können diese Anwendungen dieselben Schnittstellen nutzen wie übrige native Apps auch. Im Falle von Apache Cordova sind aber kostenpflichtige Mitgliedschaften in Stores erforderlich, Updates werden etwa im App Store von Apple erst nach einem Review freigegeben, das mindestens einige Stunden dauern wird. GitHub Electron bündelt hingegen Chromium mit einer Node.js-Runtime, sodass selbst eine Hallo-Welt-Anwendung über mehrere Dutzend MByte groß ist. Außerdem müssen sich Entwickler darum kümmern, die Chromium- und Node.js-Versionen im Anwendungsbündel aktuell zu halten. Beide Ansätze laufen außerdem nicht direkt im Webbrowser. Wenn Features wie der Dateisystemzugriff nun direkt im Web verfügbar werden, sinkt die Erforderlichkeit für Ansätze wie Apache Cordova oder GitHub Electron.
Kann ich die Fugu-Schnittstellen schon heute verwenden?
Zuletzt wurden mit jeder neuen Chromium-Version regelmäßig neue Fugu-Schnittstellen generell verfügbar gemacht, nur die Corona-Krise brachte einige Veränderungen im Release-Plan. Der überwiegende Großteil der Schnittstellen ist derzeit noch nicht browserübergreifend verfügbar. Einzelne Schnittstellen wie die Web Share API, die Project Fugu entsprangen, beahnten sich bereits ihren Weg in andere Browser: Die Web Share API wurde als erstes von Apple Safari plattformübergreifend (auf iOS und macOS) unterstützt und soll künftig auch in Firefox sowie der Desktop-Ausgabe von Chrome implementiert werden. Eine Garantie, dass die Schnittstellen auch in Mozilla Firefox oder Apple Safari implementiert werden, gibt es allerdings nicht. Allerdings haben Webentwickler hierauf Einfluss: Sie können Kontakt zu den übrigen Browserherstellern aufnehmen und dort – zum Beispiel über die jeweiligen Bugtracker der Browser-Engines – für die Implementierung mächtiger Schnittstellen eintreten.
Progressive Web Apps laufen im Browser, auf Mobilgeräten und dem Desktop.
Wir bei Thinktecture raten dazu, bei Webanwendungen zunächst immer Progressive Web Apps zu adressieren. Nur wenn Entwickler auf eine aktuelle Einschränkung im Web stoßen oder zwingend ein Deployment über native Wege (App-Stores, Executable) gebraucht wird, sollten sie einen nativen Wrapper wie Apache Cordova oder GitHub Electron nutzen. Ein Sonderfall ist die iOS/iPadOS-Plattform, auf der ausschließlich die Browserengine WebKit zugelassen ist. Auch Browser von Drittanbietern greifen auf die Safari-Engine zurück. Moderne Webschnittstellen werden dort – wenn überhaupt – oft erst mit Verzögerung bereitgestellt, Bugs manchmal erst nach Monaten geschlossen. Hier müssen Entwickler oftmals sehr schnell zum Wrapper greifen. Über die Zeit dürfte sich die Unterstützung aber bessern und mehr und mehr Schnittstellen mit nativer Power direkt im Web bereitgestellt werden, sodass der Bedarf zum Einsatz von Cordova und Electron stetig abnehmen sollte. Sobald die fehlende Fähigkeit direkt im Web verfügbar gemacht wird, können auch die nativen Wrapper samt ihrer Nachteile einfach entfallen. Die Investition in eine Webanwendung macht sich also letztlich immer bezahlt.
Fazit: Project Fugu könnte ein Game Changer werden
Project Fugu hat das Potenzial, die Anwendungsentwicklung nachhaltig zu verändern. Es ist durchaus vorstellbar, dass in Zukunft die Mehrheit der Anwendungen direkt auf Webtechnologien aufsetzt. Wer heute mit der Entwicklung einer neuen Anwendung startet, sollte daher webbasierte Anwendungsplattformen in Betracht ziehen: Angular oder Blazor eignen sich als Single-Page-Application-Frameworks zur Implementierung von Progressive Web Apps.
Progressive Web Apps, WebAssembly und Web Components sind die Säulen des modernen Web.
WebAssembly, auf das Blazor aufsetzt, ebnet praktisch jeder Programmiersprache den Weg ins Web, sodass sich hier auch interessante Migrationsszenarien erschließen. Und mit Web Components steht im Web auch ein mächtiges Komponentenmodell zur Verfügung. Dank all dieser Ansätze dürfte sich die Lücke zwischen Web-Apps und nativen Anwendungen weiter schließen.
