Thomas Steiner im Interview zu den JS Days 2020

„Mit Project Fugu wollen wir dem Web Zugriff auf die Ressourcen ermöglichen, die bisher nur nativen Apps zur Verfügung stehen, ohne Sicherheit und Privatsphäre zu gefährden“
Keine Kommentare

Unter dem Namen Project Fugu entstehen neue Möglichkeiten für das Web, rund um das Konzept der Progressive Web Apps herum. Aber worum geht es dabei genau? Thomas Steiner gehört zum Team von Project Fugu. Auf den JavaScript Days gibt er einen Einblick in die neusten Trends und Techniken. Wir haben den Speaker bereits im Vorfeld gefragt, was sich auf dem Gebiet der PWAs derzeit so tut und wie der Einstieg gelingt.

Entwickler: 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 Webdesign-Welt 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 Browser-Funktionalitäten im Zentrum des Progressive Enhancements.

Entwickler: 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 dazu packen 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 Webplattform-Standards nutzen. Gleichzeitig erhalten wir frühzeitig Feedback von Entwicklern und Browser-Herstellern, 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.

Entwickler: 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 Webplattform-Fä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) Den Bedarf der Entwickler ermitteln:

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 bugs.chromium.org eingereicht werden.

(2) Explainer erstellen:

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) Feedback und iterative Weiterentwicklung des Explainers

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 weiter zu entwickeln. 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) Den Entwurf in eine Spezifikation überführen und iterieren:

Sobald der Explainer einen guten Status erreicht hat, geht die Arbeit am Design in eine formale Spezifikation über, wobei mit den Entwicklern und anderen Browser-Herstellern 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) Ausliefern

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.

International JavaScript Conference

Effective Microservices Architecture In Node.js

by Tamar Stern (Palto Alto Networks)

React Components And How To Style Them

by Jemima Abu (Telesoftas)

Angular Camp 2020

Als Online- oder Präsenztraining!

Das 360°-Intensivtraining mit Angular-Koryphäe Manfred Steyer
Präsentiert von Entwickler Akademie

Entwickler: 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.

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

Steiner: Die Unterstützung der wichtigsten JavaScript-Sprach-Features 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 Browser-Hersteller 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.

Entwickler: 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!

Thomas Steiner
Thomas Steiner is a Developer Advocate at Google Hamburg, focused on making the Web a better place through standardization, creating and sharing best practices, and doing research. He blogs at https://blog.tomayac.com/ and tweets as @tomayac.
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 -