Begriff
WebAssembly (Wasm)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Das Web (Browser) versteht nur eine Sprache: JavaScript. JavaScript ist toll, aber langsam bei harter Mathe (Video-Schnitt, 3DGames). WebAssembly ist der Versuch, "echte" Programme im Browser laufen zu lassen. Du schreibst Code in C++, Rust oder Go. Du kompilierst ihn zu Wasm (eine Binärdatei). Der Browser führt diesen Code fast so schnell wie eine native App aus (Near-Native Speed). Es ersetzt JavaScript nicht, sondern arbeitet mit ihm zusammen (wie ein Turbo-Motor im Auto).
Merksatz: Ein binäres Instruktionsformat für eine stapelbasierte virtuelle Maschine, das es ermöglicht, Hochleistungscode (C++, Rust) sicher im Webbrowser auszuführen.
- Figma: Das Design-Tool läuft komplett im Browser, fühlt sich aber an wie eine Desktop-App. Danke an C++ und Wasm.
- Adobe Photoshop Web: Photoshop im Browser. Ohne Wasm unmöglich.
- AutoCAD Web: 3D-CAD Zeichnungen im Chrome.
1. Wasm außerhalb des Browsers (WASI)
Wasm ist so sicher (Sandbox) und schnell, dass man es auch auf dem Server nutzen will (WASI = WebAssembly System Interface). Docker-Gründer Solomon Hykes sagte: "Wenn es WASI und Wasm 2008 schon gegeben hätte, hätten wir Docker nie erfinden müssen." Es startet in Millisekunden (Docker: Sekunden) und ist extrem leichtgewichtig.
2. Garbage Collection
Anfangs hatte Wasm keinen GC (man musste Speicher manuell verwalten wie in C++). Sprachen wie Java oder C# (Blazor) mussten ihren eigenen riesigen GC als Wasm mitliefern. Neuerdings gibt es "Wasm GC", sodass Wasm den Garbage Collector des Browsers nutzen kann. Das macht Java-Apps im Browser viel kleiner.
1. Stack-Based Virtual Machine
Wasm ist im Gegensatz zu x86-Prozessoren (die Register nutzen) eine stapelbasierte (stack-based) Maschine.
Befehl: i32.add.
Das Wasm-Runtime-System nimmt die obersten zwei Zahlen vom Stapel, addiert sie und legt das Ergebnis wieder oben drauf.
Warum dieser Umweg? Weil dieser Bytecode extrem kompakt ist und sich sehr leicht von einem Browser-JIT (Just-In-Time Compiler) in schnellen Maschinencode für jede beliebige CPU (ARM, x86) übersetzen lässt. Wasm-Code ist also universell und portabel.
2. Das Lineare Speichermodell
Wasm-Module haben keinen Zugriff auf den globalen Speicher des Browsers. Sie arbeiten im Linear Memory. Das ist ein riesiges ArrayBuffer-Objekt in JavaScript.
Das hat zwei Folgen:
- Sicherheit: Ein Wasm-Programm kann nicht "ausbrechen" und den Rest der Webseite ausspionieren.
- Shared Memory: Mehrere Wasm-Instanzen (Threads) können auf demselben Speicher arbeiten (via
SharedArrayBufferund Atomics). Das ermöglicht echtes Multi-Threading im Browser, was für Video-Encoding oder komplexe Simulationen entscheidend ist.
3. Wasm Component Model & WIT
In der Produktion will man heute nicht mehr ein riesiges Monolith-Wasm-Modul bauen. Man nutzt das Component Model. Hierbei werden verschiedene Wasm-Teile (z. B. ein Parser in Rust und eine Logik-Engine in C++) miteinander verbunden. Die Kommunikation wird über WIT (Wasm Interface Types) definiert. Dabei werden komplexe Datentypen wie Strings oder Records automatisch zwischen den Modulen übersetzt (Canonical ABI). Das macht Wasm endlich so modular wie Software-Bibliotheken in anderen Ökosystemen.
Quick-Check
Kann ich DOM manipulieren?
Nein. Wasm kann nicht direkt aufdocument.getElementByIdzugreifen. Es muss JavaScript "fragen" (Glue Code). Das kostet Zeit. Wasm ist gut für Rechnen, JavaScript für UI.Ist es sicher?
Ja. Sandbox (Memory Safe). Es kann nicht auf deine Festplatte zugreifen, genau wie JS.Warum Rust?
Rust und Wasm sind beste Freunde. Rust hat keine Runtime (kleine Dateigröße) und passt perfekt in das Speichermodell von Wasm.