WebAssembly hat den Browser verlassen. Wo es 2026 wirklich läuft.

WebAssembly wurde 2017 eingeführt, um kompilierten Code im Browser nahe an nativer Geschwindigkeit auszuführen. 2026 ist diese Ursprungsgeschichte fast eine Fußnote. Interessanter ist, was außerhalb des Browsers passiert – Wasm läuft in serverlosen Funktionen, Edge Nodes, Plugin-Systemen und Datenbankerweiterungen. Das Wasm Component Model und WASI 0.2 haben dies 2024 formalisiert, und das Ökosystem hat vollständig aufgeholt.

Kurzer Rückblick: Was Wasm eigentlich ist

WebAssembly ist ein binäres Befehlsformat, das in einer sandboxed virtuellen Maschine läuft. Es kann aus C, C++, Rust, Go, Swift, Kotlin und einer wachsenden Liste anderer Sprachen kompiliert werden. Drei Eigenschaften machen es ungewöhnlich:

Deterministische Ausführung – dasselbe Binary erzeugt auf jeder Plattform jedes Mal dieselbe Ausgabe.
Speicherisolierung – ein Wasm-Modul hat keinen direkten Zugriff auf Host-Betriebssystem, Dateisystem oder Netzwerk, es sei denn, dies wird explizit über eine Schnittstelle gewährt.
Architektur-Portabilität – dasselbe .wasm-Binary läuft auf x86, ARM und RISC-V ohne Neukompilierung.

Was die Größe betrifft: Ein typisches Wasm-Modul ist 10- bis 100-mal kleiner als ein äquivalentes Docker-Container-Image. Beim Start initialisieren Wasm-Runtimes in Mikrosekunden – verglichen mit Hunderten von Millisekunden oder Sekunden für Container. Das sind keine marginalen Vorteile; sie verändern, was am Edge wirtschaftlich machbar ist.

WASI 0.2 und das Component Model – warum sie wichtig sind

WASI (WebAssembly System Interface) ist die standardisierte API, die es Wasm-Modulen ermöglicht, mit der Außenwelt zu interagieren – Datei-I/O, Netzwerk, Uhren, Zufallszahlen. WASI 0.1 war bewusst minimalistisch. WASI 0.2, im Januar 2024 ratifiziert, fügte HTTP-Anfragen und -Antworten, Sockets, Kryptografie-Primitiven und entscheidend das Component Model hinzu.

Das Component Model definiert, wie Wasm-Module miteinander komponiert werden. Ein Rust-Komponente kann eine Python-Komponente über eine typisierte, in WIT (Wasm Interface Types) definierte Schnittstelle aufrufen, ohne FFI-Overhead und mit starken Typgarantien über die Grenze hinweg. Vorher waren Wasm-Module isolierte Einheiten – nützlich, aber nicht komponierbar. Das Component Model macht Wasm zu einer echten Plattform, nicht nur zu einem Kompilierungsziel.

Das praktische Ergebnis: Du kannst jetzt eine Wasm-Anwendung bauen, indem du unabhängig entwickelte Komponenten aus verschiedenen Sprachen kombinierst, die auf Schnittstellenebene statt auf Binärebene verknüpft sind. Kein gemeinsamer Speicher, keine ABI-Kompatibilitäts-Alpträume.

Serverseitige Runtimes: Wasmtime, Wasmer, WasmEdge

Drei Runtimes haben sich als ernsthafte Produktionslösungen für serverseitiges Wasm etabliert:

Wasmtime (Bytecode Alliance, in Rust geschrieben): Produktionsreif, vollständig WASI 0.2-konform, wird in der Produktion von Fastly und Shopify genutzt. Die Referenzimplementierung für den Wasm-Standard.
Wasmer: Unterstützt WASIX – ein erweitertes WASI mit POSIX-ähnlichen Syscalls, die mehr Unix-Programme unverändert laufen lassen. Auch Docker-kompatible Wasm-Images über die Wasmer-Registry.
WasmEdge: Ein CNCF-Sandbox-Projekt, optimiert für AI Inference Workloads. Es führt GGML und llama.cpp als Wasm-kompiliert aus und ist daher die Runtime der Wahl für Edge-KI-Bereitstellungen, bei denen Docker zu schwer ist.

Über die Runtimes hinaus ist Spin von Fermyon ein Microservices-Framework, das nativ auf Wasm aufbaut – im Wesentlichen AWS Lambda, aber mit Wasm-Ausführungssemantik, WASI 0.2-Komponenten und keinem Cold-Start-Problem.

Edge Compute: Der Killer-Anwendungsfall

Wenn du verstehen willst, warum Edge-Anbieter Wasm vor allen anderen übernommen haben, denk an die Wirtschaftlichkeit: Am Edge betreibst du Tausende von Kundenfunktionen auf gemeinsam genutzter Infrastruktur und benötigst gleichzeitig Isolierung, schnelles Starten und geringen Speicher-Overhead. Container lösen die Isolierung, scheitern aber bei der Startzeit und dem Overhead pro Funktion. VMs sind noch schlechter. Wasm löst alle drei Probleme.

Cloudflare Workers nutzt V8-Isolate mit vollständiger Wasm-Unterstützung. Funktionen starten in unter 1ms. Mehr als 2 Millionen Entwickler haben Workers-Code bereitgestellt.
Fastly Compute verwendet Wasmtime mit AOT (Ahead-of-Time)-Kompilierung. Die Cold-Start-Zeit liegt buchstäblich bei 0ms – das Modul ist bereits als nativer Code kompiliert, wenn die Anfrage eintrifft. Eine in Rust geschriebene, zu Wasm kompilierte Funktion läuft innerhalb von 5–10 % der nativen Ausführungsgeschwindigkeit.
Vercel Edge Functions unterstützen Wasm-Module als First-Class-Bürger neben JavaScript.

Das Sandbox-Modell ist hier tragend: Nicht vertrauenswürdiger, benutzergelieferter Code läuft auf gemeinsam genutzter Edge-Infrastruktur ohne Container-Overhead, weil Wasms Isolierungsgarantien auf VM-Ebene und nicht auf Betriebssystemebene durchgesetzt werden. Du brauchst keinen separaten Kernel-Namensraum pro Mandant.

Plugin-Systeme: Erweitern ohne Kompromisse

Das traditionelle Plugin-Problem: Du möchtest Benutzern erlauben, deine Plattform zu erweitern, aber die Ausführung von beliebigem Benutzercode in deinem Prozess ist ein Sicherheitsdesaster. Die Optionen waren bisher: Subprozess-Isolierung (langsam, komplex), eine benutzerdefinierte Skriptsprache (eingeschränkt) oder einfach das Risiko akzeptieren (schlecht). Wasm löst das.

Extism ist ein quelloffenes Plugin-System auf Basis von Wasm. Du lieferst eine .wasm-Datei als Plugin; der Host lädt sie sicher in einer isolierten Umgebung, nur mit den Schnittstellen, die du explizit freigibst. HashiCorp nutzt es für Vault-Plugins, Grafana für Datenquellen-Plugins, und mehrere Spiel-Engines verwenden es für Modding-Systeme.
Shopifys Checkout UI Extensions laufen als Wasm-Module. Vom Händler gelieferter Code läuft in Shopifys Infrastruktur, ohne Daten exfiltrieren oder auf Systeme außerhalb der definierten Schnittstelle zugreifen zu können. Dies ist nur möglich, weil Wasms Sandboxing es standardmäßig sicher macht.
Zed (der auf Rust basierende Code-Editor) verwendet Wasm für Erweiterungen. Keine Node.js-Laufzeit erforderlich, keine npm-Abhängigkeitsketten, keine Erweiterungsprozessverwaltung. Erweiterungen laufen isoliert in Wasm mit einer klar definierten Host-Schnittstelle.

Das Muster verallgemeinert sich: Jede Plattform, die benutzergelieferten Code akzeptiert, kann das „Risiko willkürlicher Codeausführung“ durch „Wasm-Ausführung in einer definierten Schnittstelle“ ersetzen und gleichzeitig Sicherheit, Portabilität und Sprachflexibilität erhalten.

Datenbankerweiterungen

PostgreSQLs experimentelle pg_wasm-Erweiterung ermöglicht benutzerdefinierte Funktionen (UDFs) in jeder Sprache, die zu Wasm kompiliert. SingleStore unterstützt Wasm-UDFs in der Produktion. Der Wert ist direkt: Schreibe eine leistungskritische UDF in Rust, kompiliere sie zu Wasm, stelle sie bereit, ohne das Datenbank-Binary neu zu kompilieren und ohne ein Rust-Toolkit auf dem Datenbankserver zu installieren. Die Wasm-Sandbox stellt zudem sicher, dass eine fehlerhafte UDF den Datenbankspeicher nicht beschädigen kann – sie läuft im eigenen linearen Speicherbereich.

Für Analyse-Workloads eröffnet dies die Tür zu leistungsstarken benutzerdefinierten Aggregaten und Transformationen, die zuvor C-Erweiterungen erforderten oder in langsamem PL/pgSQL geschrieben wurden.

KI-Inferenz in Wasm

WasmEdge kombiniert mit llama.cpp als Wasm-kompiliert kann LLM-Inferenz auf jedem WasmEdge-Host ausführen. Der Overhead gegenüber nativer Ausführung liegt bei etwa 15–25 % – signifikant, aber für viele Anwendungsfälle akzeptabel. Der Gewinn ist Portabilität: Dasselbe Wasm-Binary läuft auf einem x86-Cloud-Server, einem ARM-Edge-Knoten oder einem RISC-V-IoT-Gerät ohne Neukompilierung.

Dies ist wichtig im IoT- und eingebetteten Edge-KI-Kontext, wo Docker aufgrund von Speicher- und Arbeitsspeicherbeschränkungen unpraktisch ist. Ein 4-Bit quantisiertes 7B-Modell, das über WasmEdge auf einem Edge-Gerät läuft, ist 2026 ein echtes Bereitstellungsmuster, keine Demo.

Was Wasm immer noch nicht gut kann

Wasms Einschränkungen sind real und sollten benannt werden:

Multi-Threading verbessert sich – der Threads-Vorschlag und der gemeinsame Speicher sind im Standard – aber korrektes Multi-Threading in Wasm zu schreiben ist immer noch schwieriger als natives Threading, und die Runtime-Unterstützung variiert.
Garbage-Collect-Sprachen (Go, Python, JavaScript) erzeugen größere Wasm-Binaries, weil die GC-Laufzeit mitkompiliert werden muss. Ein Go-Wasm-Binary ist typischerweise 5–15 MB groß. Das schrumpft mit der Integration von GC, ist aber heute noch real.
Produktionsdebugging ist schwieriger als bei nativem Code. Source Maps helfen, aber Stack Traces in Wasm sind weniger ergonomisch als natives Debuggen.
Java- und .NET-Toolchains reifen noch. Java hat experimentelle Wasm-Backends, und .NET hat Blazor für Browser-Wasm, aber serverseitiges .NET-zu-Wasm für allgemeine Anwendungsfälle ist noch nicht produktionsreif.

Wo das hinführt

Wasms Browser-Ursprung war ein historischer Zufall – ein praktischer Host, der Sandboxing, eine JS-Interop-Schicht und eine standardisierte Umgebung bot. Was der Browser tatsächlich baute, war eine universelle, portable, sandboxed Ausführungseinheit, die zufällig auch auf Servern, Edge-Knoten, Datenbanken und Plugin-Hosts funktioniert.

Das Component Model gibt Wasm endlich die Kompositionssemantik, um als echte Softwareplattform zu fungieren – Module mit typisierten Schnittstellen, komponierbar ohne gemeinsamen Speicher oder FFI-Komplexität. WASI 0.2 gab ihm das Systemzugriffsmodell, um in Nicht-Browser-Kontexten nützlich zu sein. Die Runtimes und das Tooling haben aufgeholt.

Die Frage ist jetzt nicht, ob Wasm wichtig wird. Es läuft bereits in deinem CDN, möglicherweise in deinen IDE-Erweiterungen und zunehmend in deiner Datenbank. Die Frage ist, welcher Anwendungsfall es für deinen Stack unvermeidlich macht – und für die meisten Teams ist dieser Moment näher, als sie erwarten.