WebAssembly ist dem Browser entkommen. Im Jahr 2026 wird es leise zur Runtime für alles

Als WebAssembly 2017 ausgeliefert wurde, war das Angebot einfach: ein binäres Befehlsformat, das Webbrowser mit nahezu nativen Geschwindigkeiten ausführen konnten, was Anwendungen ermöglichte, die JavaScript allein nicht bewältigen konnte. Figma übertrug seine Rendering-Engine auf WASM und machte komplexe Designsoftware im Browser realisierbar. AutoCAD Web nutzte es, um jahrzehntealten C++-Code ohne Neuschreiben auszuführen. Der Browser-Anwendungsfall war real, und die Technologie lieferte.

Was niemand so ganz vorhersah, war, dass die folgenreichsten Nutzungen von WebAssembly vollständig außerhalb des Browsers stattfinden würden.

Wie WASM der Sandbox entkam

Die entscheidende Entwicklung war WASI – die WebAssembly System Interface, vorgeschlagen von der Bytecode Alliance im Jahr 2019 und Erreichen einer stabilen 2.0-Spezifikation im Jahr 2024. WASI gab WebAssembly-Modulen eine standardisierte Schnittstelle zur Interaktion mit dem Hostsystem: Dateien lesen, Netzwerkverbindungen herstellen, auf Umgebungsvariablen zugreifen. Das klingt banal, hatte aber eine tiefgreifende Auswirkung: Ein mit WASI-Unterstützung kompiliertes WASM-Modul konnte überall dort ausgeführt werden, wo eine WASI-Runtime existiert – nicht nur in einem Browser, sondern auf einem Server, am Edge, auf einem IoT-Gerät, in einer Datenbank-Engine.

Solomon Hykes, der Schöpfer von Docker, formulierte die Bedeutung klar in einem Beitrag, der weithin zitiert wurde: "Wenn WASM+WASI im Jahr 2008 existiert hätte, hätten wir Docker nicht erschaffen müssen. So wichtig ist das." Das Versprechen war ein universelles portables Binärprogramm – einmal kompilieren, überall ausführen, mit einem integrierten Sicherheits-Sandbox.

Wo WASM im Jahr 2026 läuft

Edge Computing und serverlose Funktionen. Cloudflare Workers unterstützt WASM seit 2018, aber 2026 ist es die primäre Runtime für leistungskritische Edge-Funktionen. Fastly Compute, Fermyon Spin und Wasmer Edge führen alle WASM-Workloads auf global verteilten Edge-Knoten aus. Der Reiz ist eine Kombination aus Startzeit (submillisekundliche Kaltstarts, gegenüber 50–200 ms für eine Node.js-Funktion), Sicherheitsisolierung (jedes Modul läuft in seiner eigenen Sandbox mit expliziten Capability-Grants) und Portabilität (das gleiche Binärprogramm bei jedem Anbieter bereitstellen).

Datenbank-Erweiterbarkeit. SingleStore, DuckDB und mehrere andere Datenbanken unterstützen jetzt benutzerdefinierte Funktionen, die als WASM-Module geschrieben sind, sodass benutzerdefinierte Logik innerhalb der Query-Engine mit Zugriff auf vektorisierte Operationen und ohne den Overhead eines Roundtrips zu einem externen Prozess ausgeführt werden kann. Die WASM-UDF-Unterstützung von PostgreSQL, die 2025 stabilisiert wurde, eröffnete diese Fähigkeit für die am weitesten verbreitete Open-Source-Datenbank der Welt.

Plugin-Systeme. Zed (der Code-Editor), Extism (ein Plugin-Framework, das von Dutzenden von Anwendungen verwendet wird) und eine wachsende Zahl von Entwickler-Tools verwenden WASM als ihre Plugin-Runtime. Der Vorteil gegenüber traditionellen nativen Plugin-Systemen ist die Isolierung: Ein fehlverhaltendes Plugin kann den Host-Prozess nicht zum Absturz bringen oder auf Ressourcen außerhalb seiner Capability-Grants zugreifen. Dies ist das Modell, das Shopify für seine benutzerdefinierten App-Erweiterungen verwendet und das Figma für sein Plugin-Ökosystem verwendet.

Portable CLIs und Tooling. Das WASM-Komponentenmodell (standardisiert 2024) ermöglichte Komposition: Sie können ein CLI-Tool als eine Reihe von WASM-Komponenten erstellen, die typisierte Schnittstellen importieren und exportieren, und sie dann unabhängig davon zusammensetzen, in welcher Sprache sie ursprünglich geschrieben wurden. Eine Rust-Komponente kann die Schnittstelle einer Python-Komponente aufrufen, ohne dass eine die Implementierungssprache der anderen kennt. Dies ermöglicht eine neue Generation von sprachunabhängigem Tooling.

Das Komponentenmodell verändert die Berechnung

Das WASM-Komponentenmodell verdient besondere Aufmerksamkeit, weil es ein Problem löst, das polyglotte Software seit Jahrzehnten plagt. Bisher, wenn Sie eine in Rust geschriebene Bibliothek aus Python aufrufen wollten, mussten Sie sich mit FFI, gemeinsamem Speicher, Serialisierungsoverhead oder Subprozessaufrufen befassen. Das Komponentenmodell ersetzt all dies durch eine typsichere, sprachunabhängige Schnittstellendefinitionssprache (WIT – WebAssembly Interface Types), die Compiler für Rust, Python, JavaScript, Go, C und andere anvisieren können.

Das Ergebnis ist, dass ein Entwickler eine leistungsstarke String-Verarbeitungsbibliothek in Rust schreiben, sie als WASM-Komponente mit einer typisierten WIT-Schnittstelle exponieren und aus Python ohne FFI-Boilerplate aufrufen kann. Das Binärprogramm läuft in einer Sandbox, die Schnittstelle wird an der Grenze typgeprüft, und dieselbe Komponente funktioniert überall dort, wo die WASM-Runtime existiert.

Was noch fehlt

WASMs Wachstum außerhalb des Browsers geht mit echten Einschränkungen einher. Die Unterstützung der Garbage Collection erreichte erst 2024 einen stabilen Status, was es zuvor für Sprachen wie Python und Java, die auf GC angewiesen sind, unangenehm machte. Threads und gemeinsamer Speicher funktionieren, haben aber Vorbehalte bezüglich atomarer Operationen, die je nach Plattform unterschiedlich sind. Die Toolchain-Geschichte hat sich dramatisch verbessert – wasm-pack, cargo-component und componentize-py existieren alle – aber die Erfahrung hinkt der nativen Entwicklung in Bezug auf Debugging, Profiling und Fehlermeldungen immer noch hinterher.

Die Leistung ist für CPU-gebundene Arbeit nahezu nativ, aber nicht für Workloads, die stark auf Betriebssystemdienste angewiesen sind: Datei-I/O über WASI ist langsamer als nativ, und die Sicherheits-Grants des Capability-Modells fügen im Vergleich zu direkten Syscalls Overhead hinzu. Für latenzkritische Pfade sind diese Lücken von Bedeutung.

Die Entwicklung

Der Trend ist klar. Wasmtime (gepflegt von der Bytecode Alliance) wird in alles eingebettet, von Cloud-Anbietern über CLI-Tools bis hin zu Datenbanken. Das Komponentenmodell gewinnt schneller an Akzeptanz als jede vorherige WASM-Spezifikation. Browser-Anbieter sind sich hinsichtlich zukünftiger Funktionen einig, darunter Garbage Collection, Stack Switching für Coroutinen und Verbesserungen der Ausnahmebehandlung.

WebAssembly wird Container oder native Binärprogramme nicht für alle Workloads ersetzen. Aber für die spezifischen Anwendungsfälle, bei denen Portabilität, Sicherheitsisolierung und submillisekundliche Startzeiten wichtig sind – Edge-Funktionen, erweiterbare Anwendungen, portable Tools, gesandboxte Plugins – ist es bereits zur Standardwahl geworden. Die nächsten fünf Jahre seiner Entwicklung werden es wahrscheinlich im Vergleich zu dem browserzentrierten Binärformat, als das es begann, unkenntlich machen.