Seite 5: Jetpack vs WebExtensions

Inhaltsverzeichnis

Jetpack vs WebExtensions

c't: Ich würde gerne noch über die Erweiterungsschnittstelle mit Ihnen reden. Was mich ein bisschen überrascht hat: Ich dachte immer, das neue WebExtensions-API wäre eine Art Weiterentwicklung von Jetpack, aber anscheinend sind sie so verschieden, dass Jetpack eine Sackgasse war.

Mark Mayo: Das ist wohl richtig. In puncto Abstraktionslevel sitzt WebExtensions in der Mitte. Wir haben zwei Arten von Low-Level-Erweiterungen: XUL-Overlays und das, was wir intern Restartless Add-ons nennen. Es gibt sehr wenige Einschränkungen, was sie tun können. Das ist technisch enorm schwierig zu supporten.

Auf der anderen Seite steht Jetpack, das ein sehr hohes Abstraktionslevel hat. Es hat ähnliche Ziele wie WebExtensions – es Webentwicklern leicht zu machen. Ich glaube, wir sind aber ein bisschen zu weit gegangen. Es ist zu abstrakt, es gibt zu viel Overhead. Viele Autoren von Erweiterungen mochten es nicht besonders. Es ist nicht komplett gescheitert, denn es gibt viele Jetpack-Erweiterungen. Aber es hat nie wirklich einen großen Schub unter den Entwicklern erzeugt.

Jetpack zu langsam

Wir haben mit unseren Addon-Entwicklern geredet. Das Feedback war überraschend einheitlich: Jetpack sieht auf dem Papier toll aus, aber wenn ich damit arbeite, ich weiß nicht, fühlt es sich zu langsam an, zu schwerfällig... Das Erweiterungsmodell von Chrome, Safari und Opera schien ein besserer Mittelweg zu sein. Es setzt so niedrig an, dass man immer noch verstehen kann, wie der Browser auf eine Anweisung reagieren wird.

Nach diesem Feedback haben wir ausprobiert, einen Teil von WebExtensions nach Firefox zu mappen. Wir kamen zum gleichen Schluss wie unsere Addon-Entwickler: Es fühlt sich nicht perfekt an, wir würden es vielleicht ein klein bisschen anders machen, aber es scheint das richtige Abstraktionslevel zu sein. Jetzt ist der Umbau der Addons unser größtes Entwicklungsprojekt.

Firefox soll auch intern mehr und mehr dieser Technik einsetzen. Das war immer ein großes Problem für uns. 95 Prozent unserer Firefox-Entwickler schreiben keine Addons – sie mochten sie nie. Es ist ein Problem, wenn die Entwickler nicht mit den gleichen Werkzeugen arbeiten wie die Erweiterungs-Community. Das führt dann zu Dingen wie Australis. Australis ist toll, aber bis heute unterstützen es nicht alle Addons. Es ist eines unserer großen Ziele, die Firefox-Entwickler und die Addon-Entwickler zu vereinen. Es wird viele Jahre dauern, bis signifikante Teile von Firefox so geschrieben sind, aber man muss ja mal anfangen.

Standard für Erweiterungen

Es gibt Interesse der anderen Browser-Hersteller, einen gemeinsamen Kern für WebExtensions zu erarbeiten und einen Standard daraus zu formen. Auch wenn jeder Browser über diesen Kern hinausgehen wird, inklusive Firefox, bahnt das Cross-Plattform-Erweiterungen den Weg, und das wäre ein tolles Ergebnis. Wir haben auf dieser Grundlage System-Addons entworfen für die interne Firefox-Entwicklung. Damit werden Firefox- und Addon-Entwickler zum ersten Mal seit einer Dekade die gleichen Techniken einsetzen.

Dies passt auch zum wahrscheinlich größten Einzelprojekt, das wir uns für 2016 vorgenommen haben: der architektonische Umbau von Firefox, Electrolysis oder e10s, das ein Multiprozess-Modell bringen wird. Jetzt laufen zwar schon Plug-ins in eigenen Prozessen, nicht aber beliebige Inhalte. Damit alte Addons unter Electrolysis laufen, haben wir Wrapper gebaut, sogenannte CPOWs.

XUL- oder Jetpack-Erweiterungen?

Die meisten Erweiterungen. Nicht unbedingt XUL-Overlays. Einige wird man nie Multiprozess-sicher hinbekommen. Aber den größten Teil kann man in CPOWs packen. Allerdings kann das die Performance manchmal ziemlich verschlechtern. Wir zeigen dem Benutzer, wenn ein Addon den Browser verlangsamt, und geben ihm die Möglichkeit, es zu beenden. Natürlich wollen wir nicht, dass es CPOWs ewig geben wird – vielleicht bis Ende 2016, abhängig davon, wann wir Electrolysis in den Release-Kanal bringen. Auf jeden Fall werden wir Addon-Entwicklern ein großes Zeitfenster geben. Und wenn ihr eine neue Erweiterung schreibt: Bitte versucht, sie mit WebExtensions umzusetzen. Wir haben dazu auch viel Dokumentation veröffentlicht.

Wir empfehlen fürs Entwickeln die Firefox Developer Edition, die den letzten Stand bei den WebExtensions enthalten. Seit Version 42 sind WebExtensions aber auch im Release-Channel. Wir fügen allerdings noch APIs parallel in der Developer Edition und in den Nightlys hinzu, was wir normalerweise nicht gleichzeitig tun.

Erst gestern hatte ich ein FAQ für Addon-Entwickler gesehen, laut dem WebExtensions noch nicht da sind.

Die Entwicklung lief relativ zügig. XUL loszuwerden, wird natürlich Jahre dauern. Viele denken, dass die meisten Addons komplizierte Dinge mit XUL Overlays machen, aber deren Zahl liegt nur bei etwa 30 Prozent. Es ist eine große Aufgabe, aber auch nicht so schrecklich, wie es vielleicht scheinen mag. Mit den Autoren, die wirklich komplizierte Dinge mit XUL machen, wollen wir zusammen Lösungen finden. Wir wissen noch nicht, wie lange diese Transformation dauern wird, aber sie wird stattfinden.

Die Entscheidung für WebExtensions hatte viel mit dem Wechsel auf Electrolysis zu tun. Der andere Faktor war: Man kann wunderbare Dinge mit Addons machen, aber auch schlimme. In der Firefox-Geschichte fühlte sich die Balance meistens richtig an, aber von Anwenderberichten und automatischen Rückmeldungen wissen wir, dass über das Addon-Modell eine riesige Menge Malware in Firefox injiziert wurde. Wir haben die Linie überschritten, bei der wir noch sagen können, dass so ein offener Zugang gut ist. Deshalb führen wir Signing ein und eine sichere API – im Browser haben wir ja schon eine Technologie, die Webinhalte sicher ausführt, und diese machen wir uns jetzt zunutze. Die alte API, die zu allen Firefox-Interna Zugang hatte, lässt sich einfach nicht sicher halten.