Zum Hauptinhalt Zur Navigation

Webassembly: Browserhersteller wollen einheitlichen Bytecode fürs Web

Noch ist es nicht viel mehr als ein Plan, doch wegen der breiten Unterstützung könnte Webassembly schon bald Javascript in Teilen ablösen. Die Entwicklung des Bytecodes wird von Google, Mozilla, Microsoft und anderen vorangetrieben.
/ Sebastian Grüner
94 Kommentare News folgen (öffnet im neuen Fenster)
Eine Demoanwendung von Wasm: ein Spiel, das mit der Unity-Engine umgesetzt wurde (Bild: Luke Wagner)
Eine Demoanwendung von Wasm: ein Spiel, das mit der Unity-Engine umgesetzt wurde Bild: Luke Wagner

Javascript sollte für Menschen eigentlich leicht zu lesen sein, oft ist der vom Browser ausgeführte Code aber derart komplex, dass das nicht mehr möglich ist. Das führt wiederum zu enormen Problemen für die Browserhersteller. Gelöst werden könnten diese Schwierigkeiten durch Webassembly (Wasm): ein portables, auf geringe Größe und kurze Ladezeiten optimiertes Binärformat samt Ausführungsmodell – ein Bytecode für das Web also.

Beteiligt sind an dem Projekt derzeit die Entwickler aller großen Browserengines(öffnet im neuen Fenster) , was damit branchenübergreifend von Mozilla, Google, Mircosoft und Apple getragen wird. Geplant ist es, Wasm als einheitliches Ziel von kompilierten Programmen im Web zu etablieren. Dazu ist ein LLVM-Backend geplant(öffnet im neuen Fenster) , mit dem zum Beispiel Code in C oder C++ nach Wasm übersetzt werden kann.

Ein Bytecode für alle

Das Konzept, Bytecode im Browser zu verwenden, ist etwa mit .Net oder Java bereits umgesetzt worden. Dafür waren aber Plugins für die Browser nötig, eine gute Integration war darüber jedoch nur schwer möglich. Denn anders als bei Javascript, mit dem etwa HTML auf einer Seite manipuliert werden kann, sind die Plugins vom Rest des Browsers mehr oder weniger stark abgeschlossene Einheiten. Besonders wichtig im Vergleich zu Javascript ist vor allem das deutlich reduzierte Downloadvolumen.

Wasm ist deshalb auch eher als Ersatz für Asm.js oder Googles Portable Native Client geschaffen worden. Letzteres konnte sich bisher nicht übergreifend durchsetzen und Asm.js weist immer noch einige der Probleme von Javascript auf, auch wenn es eine klar definierte Untermenge ist.

So lässt sich das neue Binärformat in ersten Tests bis zu 20-mal schneller parsen als vergleichbares Asm.js. Dieser Geschwindigkeitsvorteil ist letztlich auch der Hauptgrund für Wasm. Bytecode ist viel näher an einer Maschinensprache und oft sehr klar definiert.

Der Bau von Compilern und Laufzeitumgebungen wird damit vereinfacht, schließlich gibt es auch kein undefiniertes Verhalten wie in manchen höheren Programmiersprachen üblich. Außerdem wird durch den Einsatz von Bytecode die Nutzung von SIMD-Instruktionen erleichtert, was wiederum die Ausführung beschleunigt.

Projekt steht erst am Anfang

Noch ist Wasm nicht viel mehr als ein Plan, dieser scheint aber sehr ausgereift. So soll es ein zu dem Binärformat isomorphes Textformat geben. Diese könnte dann etwa sehr gut zum Debuggen geeignet und ähnlich zu Assembly-Code für Hardwarearchitekturen zu benutzen sein.

Bis die Browser Wasm direkt ausführen können, soll eine Übergangslösung geschaffen werden. Dazu soll ein Polyfill genutzt werden, das Wasm zu Javascript überführt. Die bestehenden Engines sollten damit dann keine Probleme haben.

Das Design von Wasm(öffnet im neuen Fenster) wird auf Github erläutert, weitere Details sind in FAQ(öffnet im neuen Fenster) gesammelt. Der Javascript-Erfinder Brendan Eich(öffnet im neuen Fenster) bietet in seinem Blog außerdem einen Überblick zu wichtigen Fragen rund um Wasm sowie einen Ausblick, wohin sich seiner Meinung nach das neue Format entwickeln könnte.

Koordiniert wird die Arbeit an Wasm in einer Community-Arbeitsgruppe beim W3C(öffnet im neuen Fenster) , der erste Entwurf einer vorläufigen Spezifikation steht aber noch aus.


Relevante Themen