Thomas Steiner im Interview zu Project Fugu und PWAs

„Mit Project Fugu wollen wir dem Web Zugriff auf native Ressourcen ermöglichen“
Keine Kommentare

Projekt Fugu will neue Möglichkeiten für Webentwickler schaffen und dafür sorgen, dass die Lücke zwischen Webanwendungen und nativen Apps geschlossen wird. Im Zentrum stehen dabei natürlich die Progressive Web Apps – und es geht um weitaus mehr als nur die Offlinefähigkeit von PWAs.

Entwickler Magazin: Progressive Enhancement ist ein Begriff, den man im Kontext von PWAs häufiger hört. Was genau ist damit gemeint?

Thomas Steiner: Bereits im März 2003 verblüfften Nick Finck und Steven Champeon die Webdesignwelt mit dem Konzept des Progressive Enhancements:

„Rather than hoping for graceful degradation, [progressive enhancement] builds documents for the least capable or differently capable devices first, then moves on to enhance those documents with separate logic for presentation, in ways that don’t place an undue burden on baseline devices but which allow a richer experience for those users with modern graphical browser software.“

Im Jahr 2003 ging es beim Progressive Enhancement hauptsächlich um die Verwendung von Präsentationstechniken, wie damals moderne CSS-Eigenschaften, unaufdringliches JavaScript zur Verbesserung der Benutzerfreundlichkeit und sogar heute ganz basale Dinge wie skalierbare Vektorgrafiken. Heute sehe ich die Verwendung neuer Browserfunktionalitäten im Zentrum des Progressive Enhancements.

EM: Eine zentrale Rolle bei der Entwicklung von PWAs spielt Project Fugu. Was ist das, wer steht dahinter?

Steiner: Das Capabilities-Projekt (oder Projekt Fugu) soll die so genannte App-Lücke schließen: Wir wollen dem Web Zugriff auf die Ressourcen ermöglichen, die nativen Apps zur Verfügung stehen, ohne die Sicherheit, die Privatsphäre oder das Vertrauen der Benutzer zu gefährden oder ganze App-Runtimes mit dazupacken zu müssen. Indem wir Entwicklern diese neuen Werkzeuge zur Verfügung stellen, geben wir dem offenen Web die Macht, zu einem Ort zu werden, an dem fast jede Erfahrung möglich gemacht werden kann. Das Web wird damit zu einer Plattform erster Klasse für die Entwicklung von Apps, die in jedem Browser, auf jedem Betriebssystem und auf jedem Gerät laufen.

Wir entwerfen und entwickeln diese neuen Möglichkeiten auf offene und transparente Weise in der Web Incubator Community Group (WICG) des W3C, wobei wir die bestehenden Prozesse für offene Webplattformstandards nutzen. Gleichzeitig erhalten wir frühzeitig Feedback von Entwicklern und Browserherstellern, während wir die neuen Funktionen iterativ gestalten, um ihre Interoperabilität zu gewährleisten.

Wir arbeiten firmenübergreifend, unter Mitwirkung von Google, Microsoft und Intel. Die monatlichen Treffen stehen aktiven Teilnehmern offen und die Mitschriften stehen allen in der Chromium-Organisation zur Verfügung.

webinale – the holistic web conference

Diversity matters – Onlinemarketing 2020

mit Astrid Kramer (Astrid Kramer Consulting)

Das Recht auf Privatsphäre – eine Chance für UX

mit Lutz Schmitt (Lutz Schmitt Design & Consulting)

The Revenge of Structured Data

mit Stephan Cifka (Performics Germany GmbH)

IT Security Camp

Freiberuflicher Whitehat Hacker, Trainer und Security-Coach

Christian Schneider (Schneider IT-Security)

EM: Wie läuft die Entwicklung von neuen APIs im Rahmen von Project Fugu ab?

Steiner: Wir haben ein erstes Set von Features identifiziert und priorisiert, die wir von unseren Partnern abgefragt haben und die wir als entscheidend für die Schließung der Lücke zwischen dem Web und nativen Anwendungen betrachten. Interessenten können die Liste ansehen, indem sie die Bug-Datenbank von Chromium nach Fehlern durchsuchen, die mit dem Label proj-fugu gekennzeichnet sind. Was den Codenamen des Projekts betrifft: Fugu ist ein Kugelfisch, der als Delikatesse gilt, der jedoch auch tödlich giftig sein kann, wenn er nicht sorgfältig zubereitet wird. Diese Analogie funktioniert bei vielen der Zugriffsrechte, mit denen wir uns beschäftigen, recht gut. Wir haben einen Prozess entwickelt, der es ermöglicht, neue Webplattformfähigkeiten zu entwerfen und zu entwickeln, die den Bedürfnissen der Entwickler schnell, nachvollziehbar und vor allem ohne die Entwicklung von Funktionen außerhalb des Standardprozesses zu verlagern, gerecht werden.

  1. Der erste Schritt besteht darin, den Bedarf der Entwickler zu ermitteln und zu verstehen. Wie machen sie etwas heute? Und welche Probleme oder wessen Frustration werden durch neue Möglichkeiten behoben? Normalerweise werden diese Funktionen von den Entwicklern angefordert, häufig über Bugs, die auf https://bugs.chromium.org eingereicht werden.
  2. Nachdem man den Bedarf für eine neue Funktion identifiziert hat, erstellt man einen Explainer. Das ist im Wesentlichen ein Designdokument, das das Problem erklären soll, zusammen mit einem Beispielcode, der zeigt, wie das API funktionieren könnte. Der Explainer ist ein lebendes Dokument, das im Zuge der Entwicklung der neuen Funktion viele Iterationen durchlaufen wird.
  3. Sobald der Explainer in angemessenem Maße klar definiert ist, ist es an der Zeit, ihn zu veröffentlichen, Feedback einzuholen und den Entwurf iterativ weiterzuentwickeln. Das gibt Gelegenheit zur Überprüfung, ob die neue Funktion den Bedürfnissen der Entwickler entspricht und erwartungsgemäß funktioniert. Außerdem kann in dieser Phase öffentliche Unterstützung eingeholt und überprüft werden, ob wirklich Bedarf an dem Feature besteht.
  4. Sobald der Explainer einen guten Status erreicht hat, geht die Arbeit am Design in eine formale Spezifikation über, wobei mit den Entwicklern und anderen Browserherstellern zusammengearbeitet wird, um den Entwurf iterativ zu verbessern. Sobald sich der Entwurf zu stabilisieren beginnt, erstellen wir ein so genanntes Origin Trial, um mit dem Prototyping zu beginnen und mit der Implementierung zu experimentieren. Origin Trials ermöglichen es Entwicklern, neue Funktionen mit echten Benutzern auszuprobieren und Feedback zur Implementierung zu geben.
  5. Wenn das Origin Trial abgeschlossen ist, die Spezifikation ausgereift ist und alle anderen Startschritte abgeschlossen sind, ist es an der Zeit, das Feature im stabilen Channel auszuliefern. Wir arbeiten auch dann noch immer mit anderen Implementierungen und Entwicklern zusammen, um die Spezifikation zu verfeinern, Verbesserungen und Korrekturen am Design mit anderen Anbietern zu untersuchen und darauf hinzuarbeiten, die Spezifikation zu einem formalen Standard zu machen. Man muss allerdings beachten, dass viele Ideen nie über das Stadium des Explainers oder des Origin Trials hinauskommen. Es ist in Ordnung, ein Feature nicht zu liefern, weil es kein Bedürfnis der Nutzer erfüllt. Die wichtigsten Meilensteine sind hier mit öffentlichen Diskussionen und Genehmigungen über den API-Einführungsprozess von Chromium formalisiert.

EM: Welche Features würdest du gern in einem browserübergreifenden PWA-Standard sehen?

Steiner: Wenn ich mir was wünschen könnte, hätte ich gern alles, was in unserem API-Tracker steht. Wenn ich mir eins aussuchen müsste, wäre es das Native File System API, da es wirklich neue Möglichkeiten für App-Entwickler eröffnet, aber ich würde da nicht aufhören wollen.

EM: Es zeigt sich aber auch, dass diese Standards teilweise schwierig durchzusetzen sind. Woran liegt das?

Steiner: Die Unterstützung der wichtigsten JavaScript-Sprachfeatures in den großen Browsern ist super. Die ECMAScript-2016+-Kompatibilitätstabelle von Kangax ist fast ausschließlich grün, und die Browserhersteller sind sich im Allgemeinen einig und schnell in der Implementierung. Im Gegensatz dazu gibt es weniger Einigkeit über das, was wir umgangssprachlich Fugu-Funktionen nennen. Um einen Eindruck von der Debatte um diese Funktionen zu bekommen, wenn es um die verschiedenen Browserhersteller geht, empfehle ich, die Diskussionen um die Frage nach der Position von WebKit zu Web NFC oder die Anfrage zu Mozillas Meinung zu On Screen Wake Lock zu lesen – beide Diskussionen enthalten Links zu den jeweiligen Spezifikationen. In einigen Fällen kann das Ergebnis dieser Diskussionen über die jeweiligen Positionen lauten, dass man sich darauf einigt, sich nicht einig zu sein. Das ist in Ordnung.

EM: Welchen Tipp kannst du Entwicklern geben, die in die Arbeit mit PWAs einsteigen wollen?

Steiner: Wenn man zum ersten Mal mit PWAs arbeitet, muss man sicherstellen, dass man den Lifecycle von Service Workern versteht. Wir haben ein großartiges Codelab, das alle Details abdeckt. Bei Fugu-Features ist mein Tipp, frühzeitig Feedback einzureichen. Wenn einem etwas merkwürdig vorkommt, sollte man nicht zögern, sich via GitHub oder auch direkt bei mir zu melden. Ich gebe das Feedback gerne weiter. Man sollte seine Anwendungen auch immer auf echten Geräten und in echten Browsern testen und nicht nur in den DevTools ein Mobilgerät simulieren. Und schließlich: Verinnerlicht die Idee des Progressive Enhancements und genießt das Hacken!

EM: Vielen Dank für dieses Interview!

Die Fragen stellte Ann-Cathrin Klose

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -