🧰Toolchains, WASI & Component Model

Kaum jemand schreibt WAT von Hand: Compiler übersetzen Rust, C/C++, Go, Kotlin, C# und andere Sprachen nach Wasm. Außerhalb des Browsers sorgen WASI und das Component Model für standardisierte Schnittstellen.

🏗️Von der Quellsprache zum Modul

Rust · Quelltext (nur Anzeige)

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[wasm_bindgen]
pub fn gruss(name: &str) -> String {
    format!("Hallo, {name}!")   // String über den linearen Speicher
}

Bauen

# Browser: npm-Paket mit JS-Klebecode in ./pkg
wasm-pack build --target web

# Ohne Browser: WASI 0.2 (Component Model)
rustup target add wasm32-wasip2
cargo build --release --target wasm32-wasip2
wasmtime target/wasm32-wasip2/release/app.wasm

Werkzeug: wasm-bindgen + wasm-pack (Browser) · Ziel wasm32-wasip2 (WASI)

wasm-bindgen erzeugt die JavaScript-Klebeschicht (Strings, Objekte, Closures); wasm-pack baut daraus ein npm-Paket.

wasm32-wasip2 ist seit Rust 1.82 (Oktober 2024) ein Tier-2-Ziel.
Die Organisation „rustwasm“ wurde 2025 aufgelöst: wasm-bindgen hat eine eigene GitHub-Organisation mit neuen Maintainern, wasm-pack wird von einem der ursprünglichen Maintainer weitergeführt.

🧱WASI und Component Model

Ein Core-Modul kennt nur Zahlen und linearen Speicher. Komponenten beschreiben ihre Schnittstellen in WIT mit echten Typen (string, list, record, result …); die Canonical ABI legt fest, wie diese Werte in den linearen Speicher abgebildet werden.

Die Komponente bekommt nur die Schnittstellen, die der Host ihr gibt („capability-based“): ohne wasi:filesystem-Freigabe kein Dateizugriff.

rechner.wit (WebAssembly Interface Types)

package beispiel:rechner@0.1.0;

interface rechnen {
  add: func(a: s32, b: s32) -> s32;
  gruss: func(name: string) -> string;
}

world rechner {
  import wasi:clocks/wall-clock@0.2.0;
  export rechnen;
}

🗓️ WASI-Versionen

Preview 1 (wasi_snapshot_preview1) – Core-Modul-Importe im POSIX-Stil
0.2.0 – Januar 2024, erstmals auf Basis des Component Model; Patch-Releases alle zwei Monate bis 0.2.12
0.3.0 – 11. Juni 2026: natives async mit stream<T> und future<T>; wasi:io entfällt
0.3.1 – 11. August 2026; weitere Patch-Releases alle zwei Monate geplant
1.0 – noch ohne Termin

Quelle: wasi.dev/roadmap (abgerufen 25.09.2026)

🌍Wasm außerhalb des Browsers

💡 Wasmtime

Laufzeit der Bytecode Alliance mit dem Code-Generator Cranelift; unterstützt WASI 0.2 und das Component Model.
wasmtime run app.wasm

💡 Wasmer

Eigenständige Laufzeit mit mehreren Compiler-Backends und Paketverzeichnis.
wasmer run app.wasm

💡 Edge: Cloudflare Workers

Workers führen neben JavaScript auch Wasm-Module aus – z. B. mit Rust über das Paket workers-rs. Startet in Isolates statt Containern.

✅ Plugins & Sandboxing

Weil ein Modul nur über Importe mit der Welt spricht, eignet sich Wasm für Erweiterungen in Anwendungen (z. B. Proxy-Filter, Datenbank-Funktionen), ohne dem Plugin den ganzen Prozess zu öffnen.

🏢Beispiele aus der Praxis

Nur Beispiele mit öffentlicher Quelle.

🗃️

sql.js

SQLite, mit Emscripten nach WebAssembly übersetzt: eine vollständige SQL-Datenbank im Browser, die Datenbankdatei liegt als Uint8Array im Speicher. Das SQLite-Projekt bietet inzwischen auch einen eigenen offiziellen Wasm-Build an.

https://github.com/sql-js/sql.js

https://sqlite.org/wasm

🎨

Figma

Der in C++ geschriebene Editor-Kern läuft im Browser. Figma berichtete 2017, dass der Umstieg von asm.js auf WebAssembly die Ladezeit um den Faktor 3 verkürzte.

https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/

🖌️

Photoshop im Web

Adobe hat große Teile der C++-Codebasis von Photoshop mit Emscripten nach WebAssembly gebracht; beschrieben in der Fallstudie „Photoshop's journey to the web“ auf web.dev (2021).

https://web.dev/articles/ps-on-the-web