WebAssembly

WebAssembly
colspan="2" class="notheme" style="text-align:center; background-color:#Vorlage:Standardfarbe;" | Logo von Webassembly
Basisdaten
Erscheinungsjahr:	2017
Designer:
Entwickler:	Bytecode Alliance
Aktuelle Version	()
Beeinflusst von:	asm.js, Google Native Client
Betriebssystem:
Lizenz:	Apache-Lizenz
webassembly.org

WebAssembly (Wasm<ref> Abgerufen am 9. Juni 2022. </ref>) ist ein offener Standard, der vom W3C festgelegt wurde. Er definiert einen Bytecode zur Ausführung von Programmen innerhalb von Webbrowsern, kann aber auch außerhalb von diesen genutzt werden. Ziel der Entwicklung war es, leistungsstärkere Webanwendungen als bisher zu ermöglichen, sowohl was die Ladezeiten als auch die Ausführung betrifft. Das Projekt wird von allen großen Entwicklern von Browser-Engines, also Mozilla, Microsoft, Google und Apple, unterstützt.<ref>Peter Bright: In: 18. Juni 2015, abgerufen am 6. Juli 2017 (). </ref><ref>Sebastian Grüner: In: 18. Juni 2015, abgerufen am 6. Juli 2017. </ref>

Seit März 2017 wird die Version 1 standardmäßig mit Chrome, Firefox, Edge und Webkit ausgeliefert.<ref>Luke Wagner: Abgerufen am 8. Juni 2018 (). </ref><ref> Abgerufen am 8. Juni 2018. </ref> Der Standard wurde am 5. Dezember 2019 offiziell festgelegt.<ref>heise online: Abgerufen am 30. April 2020. </ref><ref> Abgerufen am 30. April 2020. </ref> Weitere Funktionen wurden einzeln standardisiert und sind in Entwicklung oder in einigen Implementierungen bereits enthalten.<ref> Abgerufen am 8. Juni 2018. </ref> Version 2 der Spezifikation lag seit April 2022 als Entwurf vor.<ref> Abgerufen am 22. April 2022. </ref> Eine Version 3 wurde im September 2025 vorgestellt.<ref> Abgerufen am 23. September 2025. </ref>

Bytecode Alliance

Zur Unterstützung der Entwicklung gründeten im November 2019 Mozilla, Fastly, Intel und Red Hat die Bytecode-Allianz.<ref> 12. November 2019, abgerufen am 3. Juni 2021 (). </ref> Im April 2021 wurde diese offiziell als Non-Profit-Organisation registriert und nahm neue Mitglieder auf.<ref> 28. April 2021, abgerufen am 3. Juni 2021 (). </ref> Im Oktober 2022 hatte sie 32 Mitglieder, im September 2025 waren es noch 26.<ref> Abgerufen am 25. Oktober 2022 (). </ref>

Entwicklung von WebAssembly-Code

Die Entwicklung von Webassembly-Code ist in einer Reihe von Programmiersprachen möglich, für weitere Sprachen gibt es Laufzeitsysteme als WebAssembly.<ref>appcypher: 9. Juni 2021, abgerufen am 9. Juni 2021. </ref>

Neben dem Bytecode (wasm) gibt es eine Textform (wat), aus der der Bytecode mit Hilfe des Kommandos wat2wasm unmittelbar erzeugt werden kann.<ref> Abgerufen am 5. Juni 2021. </ref>

Außerdem werden die Programmiersprachen C und C++ unterstützt.<ref> In: Abgerufen am 6. Juli 2017 (). </ref> Das Tool Emscripten ist hierbei in der Lage, nahezu jeden C- und C++-Quellcode in ein WebAssembly-Modul zu kompilieren. Zusätzlich wird der notwendige JavaScript-Code zum Laden und Ausführen dieses Moduls sowie ein HTML-Dokument zur Anzeige generiert.<ref> In: Abgerufen am 3. März 2019 (). </ref> Auch die Entwicklungsumgebung Unity verwendet Emscripten, um WebAssembly-Code (z. B. für Browserspiele) zu erzeugen.<ref>Unity Technologies: Abgerufen am 5. Juni 2021 (). </ref>

Auch kompilieren Rust, Go und Zig nativ nach WebAssembly.<ref name="github-46115">bors: In: 25. November 2017, abgerufen am 4. Februar 2018 (). </ref><ref>Vorlage:Cite book/NameVorlage:Cite book/Name: [ ] , archiviert vom Vorlage:Referrer (nicht mehr online verfügbar) am Vorlage:Cite book/URL; abgerufen im 1. Januar 1. Vorlage:Cite book/URLVorlage:Cite book/MeldungVorlage:Cite book/Meldung2Vorlage:Cite book/MeldungVorlage:Cite book/MeldungVorlage:Cite book/MeldungVorlage:Cite book/MeldungVorlage:Cite book/Meldung</ref><ref> Abgerufen am 27. August 2018. </ref><ref> Abgerufen am 12. Februar 2023. </ref> Umfragen zufolge ist Rust die beliebteste Sprache für Wasm-Anwendungen.<ref>heise online: Abgerufen am 24. Juni 2021. </ref>

Beim JWebAssembly-Projekt wird Java-Bytecode nach WebAssembly übersetzt (experimentell).<ref> i-net /// software, 8. Juni 2021, abgerufen am 9. Juni 2021. </ref><ref> In: 23. März 2020, abgerufen am 9. Juni 2021 (). </ref> Es gibt für Java jedoch auch einen proprietären Compiler namens CheerpJ.<ref> In: Abgerufen am 9. Juni 2021 (). </ref>

AssemblyScript ist eine Variante des JavaScript basierten TypeScript, die speziell für WebAssembly entwickelt wurde. Sie ermöglicht auch die Integration von Low-Level-Funktionen.<ref> Abgerufen am 24. Juni 2021. </ref>

Beim Blazor-Framework (für WebAssembly) wird ein Laufzeitsystem (IL-Interpreter) als WebAssembly geladen, sodass im Endeffekt die Programmiersprachen C# und F# im Browser genutzt werden können. Ab .NET 6 kann die Übersetzung in WebAssembly-Bytecode zum Entwicklungszeitpunkt (AOT) erfolgen, die App ist dann größer.<ref>guardrex: Abgerufen am 9. November 2021 (). </ref>

Über das pyodide-Projekt kann Python im Browser genutzt werden (experimentell).<ref> In: 9. Juni 2021, abgerufen am 9. Juni 2021. </ref>

Jetbrains hat einen Compiler für Kotlin nach WebAssembly implementiert (experimentell).<ref> Abgerufen am 8. Juni 2023 (). </ref>

Nutzung außerhalb des Browsers

Über eine Schnittstelle namens WASI kann WebAssembly auch außerhalb von Browsern benutzt werden.<ref>heise online: Abgerufen am 28. März 2019. </ref> Hierbei startet das Kommando wasmtime eine Stand-Alone Laufzeitumgebung für WebAssembly. Die Laufzeitumgebung für WebAssembly kann außerdem in verschiedene Sprachen eingebettet werden.<ref> Bytecode Alliance, 3. Juni 2021, abgerufen am 3. Juni 2021. </ref><ref> Bytecode Alliance, abgerufen am 3. Juni 2021 (). </ref> Daneben gibt es auch eine Micro Runtime mit reduzierter Speichernutzung.<ref> Bytecode Alliance, 4. Juni 2021, abgerufen am 4. Juni 2021. </ref> Beide stehen unter der Apache-Lizenz 2.0.

Wasmer

Mit Wasmer gibt es zudem eine weitere Implementierung einer Laufzeitumgebung für WebAssembly für verschiedene Nutzungsarten, die im Januar 2021 erstmalig mit einer stabilen Version erschien.<ref> Abgerufen am 4. Juni 2021. </ref><ref> Abgerufen am 4. Juni 2021 (). </ref><ref>heise online: Abgerufen am 4. Juni 2021. </ref><ref>Tom Preston-Werner: Abgerufen am 16. Januar 2023. </ref> Die Implementierung steht unter der MIT-Lizenz. Wasmer Inc. ist dabei auch der Firmenname der Herausgeber. Weitere Komponenten wie ein Paketmanager (WAPM) wurden später ergänzt.<ref>heise online: Abgerufen am 24. November 2022. </ref><ref> Abgerufen am 24. November 2022. </ref> Mit WASIX wurde WASI erweitert, dies ist jedoch kein Standard.<ref>Paul Krill: 21. Juni 2023, abgerufen am 15. September 2023 (). </ref>

Compiler

WebAssembly-Implementierungen verwenden in der Regel entweder die AOT- oder die JIT-Kompilierung, können aber auch einen Interpreter verwenden. Während die ersten Implementierungen in Webbrowsern gelandet sind, gibt es auch Nicht-Browser-Implementierungen für allgemeine Zwecke, darunter Wasmer, Wasmtime oder WAMR, wasm3, WAVM und viele andere.

Da die ausführbaren Dateien von WebAssembly vorkompiliert sind, können sie mit einer Vielzahl von Programmiersprachen erstellt werden, entweder durch direkte Kompilierung nach Wasm oder durch Implementierung der entsprechenden virtuellen Maschinen in Wasm. Es gibt etwa 40 Programmiersprachen, die Wasm als Kompilationsziel unterstützen.

Emscripten kompiliert C und C++ nach Wasm unter Verwendung von Binaryen und LLVM als Backend. Das Emscripten SDK kann den Quellcode jeder LLVM-unterstützten Sprache (wie C, C++ oder Rust u. a.) in eine Binärdatei kompilieren, die in der gleichen Sandbox wie JavaScript-Code läuft.[Anmerkung 1] Emscripten bietet Bindungen für mehrere häufig verwendete Umgebungsschnittstellen wie WebGL.

Ab Version 8 kann ein eigenständiges Clang C und C++ zu Wasm kompilieren. Ursprünglich war es das Ziel, die Kompilierung von C und C++ zu unterstützen, aber die Unterstützung für andere Quellsprachen wie Rust, .NET-Sprachen und AssemblyScript (TypeScript-ähnlich) ist ebenfalls im Kommen.

Nach der MVP-Veröffentlichung fügte WebAssembly Unterstützung für Multithreading und Garbage Collection hinzu, was die Kompilierung für Programmiersprachen mit Garbage Collection wie C# (unterstützt über Blazor), F# (unterstützt über Bolero mit Hilfe von Blazor), Python und sogar JavaScript ermöglichte, wo die Just-in-Time-Kompilierungsgeschwindigkeit des Browsers als zu langsam angesehen wird.

Eine Reihe anderer Programmiersprachen wird in gewissem Umfang unterstützt, darunter Python, Julia und Ruby.

Eine Reihe von Systemen kann Java und andere Bytecode-Sprachen in JavaScript und WebAssembly kompilieren. Dazu gehören CheerpJ, JWebAssembly und TeaVM. Sie alle nehmen Java-Bytecode-.class-Dateien als Eingabe, sodass auch andere JVM-Sprachen wie Groovy und Scala verwendet werden können. Kotlin unterstützt WebAssembly direkt.

Beschränkungen

Im Allgemeinen erlaubt WebAssembly keine direkte Interaktion mit dem Document Object Model (DOM). Alle Interaktionen müssen über JavaScript Interop laufen. (Sicherheitsüberlegungen siehe unten)

WebAssembly wird auf Desktops und Mobiltelefonen unterstützt, aber in der Praxis (für speicherintensive Zuweisungen, wie z. B. bei der Unity-Spielengine) gibt es „schwerwiegende Einschränkungen, die es unmöglich machen, viele Anwendungen zuverlässig auf mobilen Browsern bereitzustellen [...] Derzeit ist die Zuweisung von mehr als ~300 MB Speicher in Chrome auf Android nicht zuverlässig, ohne auf Chrome-spezifische Workarounds zurückzugreifen, und auch nicht in Safari auf iOS.“

Alle großen Webbrowser erlauben WebAssembly, wenn keine Content Security Policy angegeben ist oder wenn „unsafe-eval“ verwendet wird, aber ansonsten verhalten sich die großen Webbrowser unterschiedlich. In der Praxis kann WebAssembly in Chrome ohne „unsafe-eval“ nicht verwendet werden, während ein Worker-Thread-Workaround verfügbar ist.

Sicherheitsüberlegungen

Vorlage:Hinweisbaustein Im Juni 2018 stellte ein Sicherheitsforscher die Möglichkeit vor, dass WebAssembly verwendet werden kann, um Browser-Abschwächungen für Spectre- und Meltdown-Sicherheitslücken zu umgehen, sobald Unterstützung für Threads mit gemeinsamem Speicher hinzugefügt wird. Aufgrund dieser Bedenken legten die WebAssembly-Entwickler die Funktion auf Eis. Um jedoch diese zukünftigen Spracherweiterungen zu erforschen, fügte Google Chrome im Oktober 2018 experimentelle Unterstützung für den WebAssembly-Thread-Vorschlag hinzu.

WebAssembly wurde dafür kritisiert, dass es Schadsoftware-Autoren, Betrügern und Phishing-Angreifern leichter fällt, Beweise zu verstecken; WebAssembly ist auf dem Rechner des Nutzers nur in kompilierter Form vorhanden, was „[die] Erkennung von Schadsoftware erschwert.“ Die Geschwindigkeit und Unauffälligkeit von WebAssembly haben dazu geführt, dass es für verstecktes Krypto-Mining auf dem Gerät des Website-Besuchers verwendet wird. Coinhive, ein inzwischen eingestellter Dienst, der das Mining von Kryptowährungen in den Browsern von Website-Besuchern ermöglicht, behauptet, sein „Miner verwendet WebAssembly und läuft mit etwa 65 % der Leistung eines nativen Miners.“ Eine Studie der Technischen Universität Braunschweig vom Juni 2019 analysierte die Verwendung von WebAssembly in den Alexa-Top-1-Millionen-Websites und stellte fest, dass die vorherrschende Verwendung für böswilliges Krypto-Mining war und dass Malware mehr als die Hälfte der untersuchten WebAssembly-verwendenden Websites ausmachte.

Eine Studie der Universität Stuttgart vom April 2021 ergab, dass das Krypto-Mining seither an den Rand gedrängt wurde und auf unter 1 % aller WebAssembly-Module gefallen ist, die aus einer Vielzahl von Quellen zusammengetragen wurden, darunter auch die Alexa-Top-1-Million-Websites.

Die Fähigkeit, große Mengen an Code effektiv zu verschleiern, kann auch dazu genutzt werden, um Werbeblocker und Datenschutz-Tools zu umgehen, die das Tracking im Web verhindern, wie Privacy Badger (Zitat).

Da WebAssembly nur einen strukturierten Kontrollfluss unterstützt, eignet es sich für Sicherheitsüberprüfungsmethoden, einschließlich der symbolischen Ausführung. Zu den aktuellen Bemühungen in dieser Richtung gehört die symbolische Ausführungsmaschine Manticore.

Weblinks

• Offizielle Website (englisch)
• Vorlage:GitHub (englisch)
• In: 29. Januar 2018, abgerufen am 9. Februar 2018 (). 
• Details zum Projekt von Brendan Eich (englisch)
• Michael Gerhäuser: In: 28. September 2018, abgerufen am 3. März 2019. 

Einzelnachweise

<references />