Original-URL des Artikels: https://www.golem.de/news/web-bytecode-so-sieht-die-zukunft-fuer-webassembly-aus-1811-137389.html    Veröffentlicht: 01.11.2018 07:00    Kurz-URL: https://glm.io/137389

Web-Bytecode

So sieht die Zukunft für Webassembly aus

Webassembly ist eine der vielversprechendsten Webtechnologien, doch noch fehlen wichtige Features. Die Mozilla-Entwicklerin Lin Clark erklärt, welche Entwicklungen bevorstehen.

Webassembly ist aktuell eine der spannendsten Web-Technologien. Seit etwas mehr als einem Jahr wird sie von allen großen Browsern - Firefox, Chrome, Safari, Edge - unterstützt. Seither ist es um den neuen Standard relativ ruhig geworden. Ein großer Hype blieb bisher aus. Woran das liegt, wie es um das Projekt steht und wohin die Reise im Jahr 2019 gehen könnte, hat die Mozilla-Entwicklerin Lin Clark in einem Vortrag auf der Github Universe Konferenz und in einem zugehörigen Blogpost verraten.

Webassembly, kurz WASM, ist ein Bytecode, der von Browsern direkt in einer virtuellen Maschine ausgeführt wird. Entwickler schreiben Programme aber nicht direkt in Webassembly, sondern es handelt sich um ein Compile-Ziel. Andere Programmiersprachen werden also nach WASM kompiliert. Es werden bereits viele Sprachen unterstützt, aber als Paradebeispiele gelten bisher C, C++ und vor allem die von Mozilla entwickelte Sprache Rust.

Webassembly soll die Monopolstellung von Javascript als der einzigen Sprache, die ein Browser ausführen kann, beenden. Im Gegensatz zu Javascript wird Webassembly vorab kompiliert und der resultierende, kompakte Bytecode zum Nutzer geschickt. Durch die geringere Dateigröße, den höheren Grad der Optimierung, statische Typisierung und viele weitere kleine Optimierungen verspricht WASM einen Geschwindigkeitsvorteil gegenüber Javascript, vor allem in rechenintensiven Anwendungsgebieten.

Heutige WASM-Implementierung ist nur eine Minimalversion

Was vielen Interessenten nicht klar ist: Die vor einem Jahr erfolgte Unterstützung von WASM in allen großen Browsern stellte nur den ersten Meilenstein der Entwicklung, ein Minimum Viable Product (MVP), dar, also eine minimale Variante. Webassembly ist keinesfalls fertig. Ganz im Gegenteil, die Sprache steht noch ganz am Anfang. Nach der Aufmerksamkeitswelle bezüglich der breiten Browser-Unterstützung folgten nur noch wenige Berichte über den produktiven Einsatz von Webassembly. Das liegt daran, dass der Sprache noch viele Teile fehlen um wirklich überzeugen zu können.

Der Übersichtlichkeit halber hat Clark die einzelnen fehlenden Features inhaltlich gruppiert. Die erste Gruppe beinhaltet Features, die dafür nötig sind, um komplexe und große Desktop-Anwendungen (beispielsweise Photoshop oder CAD-Programme) einfach in Webassembly realisieren zu können.

Komplexe Anwendungen brauchen 64 bit, Threads und SIMD

Eine der größten Limitierungen von WASM für komplexe Anwendungen ist das Fehlen von Threads. Dieser Missstand soll schon sehr bald behoben werden, indem eine Thread-Unterstützung auf Basis von Web Workern - ähnlich wie bei Javascript - implementiert wird. Die Arbeiten an dem zugehörigen Proposal sind abgeschlossen, aber durch die Spectre-Sicherheitslücken mussten die Browser-Hersteller die notwendigen Shared Array Buffer temporär deaktivieren, die für die Umsetzung benötigt werden. Diese Unterstützung sollte aber bald wieder aktiviert werden. Die Einführung der Threads in der ersten Hälfte 2019 erscheint daher realistisch. Experimentierfreudige Nutzer können eine frühe Implementierung der WASM-Threads in der aktuellen Chrome Version 70 testen.

Ebenfalls notwendig, um die Fähigkeiten und Performance von WASM für große Anwendungen anzupassen: SIMD und 64 Bit. SIMD bringt die Unterstützung für eine bestimmte Klasse von Prozessor-Opcodes, die es ermöglichen, gleichartige Rechenoperationen mit mehreren Operanden auf einmal auszuführen. Diese Art von Operationen wird häufig für Bild-, Ton- und Video-Bearbeitung gebraucht. Ebenfalls hilfreich für komplexe Anwendungen ist die Unterstützung von 64 Bit Wortlänge. Damit können Webassembly-Anwendungen auch mehr als 4 Gigabyte Speicher addressieren. Die SIMD-Implementierung ist schon relativ weit gediehen und wird voraussichtlich auch im Jahr 2019 fertiggestellt werden. Die Arbeiten an der 64-Bit-Unterstützung befinden sich dagegen leider noch im Anfangsstadium.

Web-Frameworks: Wann benutzen React, Angular und Co. Webassembly?

Mittelfristig soll Webassembly so nützlich werden, dass auch die großen Javascript-Frameworks wie React, Angular und Vue den Nutzen erkennen und es einsetzen. Ein erster Ansatzpunkt für die Integration von WASM wäre es, rechenintensive Teile der Frameworks, zum Beispiel die DOM-Vergleichs-Algorithmen, in einer WASM-Sprache zu implementieren und dann die kompilierten Module in die Frameworks zu integrieren. In einer späteren Stufe wäre es sogar denkbar, dass auch Nutzer einzelne, hauptsächlich logikschwere Komponenten innerhalb der Frameworks in Form von Webassembly-Modulen integrieren könnten.

Als Blocker für diese Entwicklung identifiziert Clark fehlende Features, die man von anderen High-Level-Sprachen gewohnt ist: Allen voran mangelt es der Sprache noch an einer Garbage Collection. Bisher müssen Entwickler Garbage Collection selbst in ihren WASM-Modulen implementieren. In Zukunft soll aber der browsereigene Garbage Collector auch den Webassembly-Speicher verwalten und dort aufräumen. Dieses Thema ist in der Umsetzung sehr aufwendig. Auch wenn viel daran gearbeitet wird, ist eine Fertigstellung im Jahr 2019 fraglich.



Webassembly außerhalb des Browsers: Keine nativen Node-Module mehr?

Langfristig gesehen soll Webassembly auch aus dem Browser ausbrechen. Ein erstes Anwendungsgebiet wird dabei sicherlich Node.js sein. Die Javascript-Laufzeitumgebung basiert auf der V8-Engine des Chrome-Browsers und unterstützt deswegen auch heute schon Webassembly. Die neue Sprache könnte einen großen Nachteil von Node.js addressieren: Native Module. Denn in der Node.js-Welt werden häufig Module verwendet, die nicht in JavaScript sondern in C/C++ geschrieben sind.

Häufig handelt es sich dabei um große, komplexe Bibliotheken, die aus Geschwindigkeits- oder Portabilitäts-Gründen nicht in JavaScript geschrieben sind. Der C/C++-Code solcher Bibliotheken könnte in Zukunft einfach nach Webassembly portiert werden und Node.js könnte den Plattform-unabhängigen Bytecode direkt ausführen. Um für die Macher solcher Bibliotheken attraktiv zu werden, fehlt Webassembly allerdings noch eine sichere Möglichkeit, Zugriff auf Betriebssystem-Ressourcen (zum Beispiel Sockets und das Dateisystem) zu erhalten. Node.js müsste eine solche API nach Vorbild des POSIX-Interfaces bereitstellen.

Eigene Webassembly Runtime: Portable CLI-Tools

In sehr ferner Zukunft könnte Webassembly auch eine eigene, native Laufzeitumgebung bekommen. Erste Experimente und Ansätze dazu existieren bereits, zum Beispiel in Form von wasmtime oder wasmjit. Damit würde sich die Sprache endgültig aus dem Browser beziehungsweise der Javascript-Engine herauslösen. Damit könnten dann portable Kommandozeilen-Tools in Webassembly verfasst werden.

Bei all der Träumerei über die Potenziale machen die Leute hinter Webassembly immer wieder darauf aufmerksam, dass WASM Javascript nicht komplett ersetzen soll. Hinter den Kulissen heutiger Webanwendungen sollen aber immer mehr Bibliotheken ganz oder teilweise als Webassembly ausgeliefert werden, wenn es nach den Initiatoren geht. Mit allen geplanten Features könnte 2019 das Jahr werden, in dem Webassembly zum ersten Mal Einzug in einige produktive Anwendungen erhält. Eine massenhafte Verbreitung wird aber vermutlich noch etwas länger auf sich warten lassen.  (mos)


Verwandte Artikel:
Wasmjit: Webassembly-Laufzeit entsteht als Linux-Kernel-Modul   
(27.09.2018, https://glm.io/136814 )
Mozilla: Firefox beschleunigt Webassembly-Aufrufe über Javascript   
(06.07.2018, https://glm.io/135353 )
C++-Framework: Qt arbeitet an Webassembly-Support   
(24.04.2018, https://glm.io/134027 )
Wasm-Pack: Mozilla packt Rust-Software für NPM   
(19.04.2018, https://glm.io/133944 )
Web-Bytecode: Mozilla stellt Online-IDE für Webassembly vor   
(12.04.2018, https://glm.io/133807 )

© 1997–2019 Golem.de, https://www.golem.de/