WebAssembly hat den Browser verlassen. Jetzt läuft es in Shopify, Cloudflare und Ihrem Kubernetes-Cluster.

WebAssembly startete 2017 als Lösung für ein Browser-Problem: JavaScript war für performancekritische Aufgaben zu langsam, native Plugins zu riskant. Die Antwort war ein kompaktes Binärformat, das naturnah in einer sandboxed Browser-Umgebung läuft – sicher, portabel und schnell. Es funktionierte. Videobearbeitungs-, CAD- und wissenschaftliche Simulationsanwendungen zogen ins Web. Figma verbesserte seine Performance um den Faktor drei, nachdem die Rendering-Engine auf C++ kompiliert und in WASM umgewandelt wurde.

Dann geschah etwas Unerwartetes. Ingenieure fragten sich, ob ein schnelles, sandboxed, sprachunabhängiges Binärformat auch woanders als im Browser nützlich sein könnte. Die Antwort war Ja – und das Ökosystem, das um diese Antwort herum entstanden ist, ist inzwischen reif genug für den Produktionseinsatz.

Das Component Model: Das fehlende Stück, das endlich da ist

Die ursprüngliche WebAssembly-Spezifikation hatte eine grundlegende Einschränkung für den serverseitigen Einsatz: Zwei aus verschiedenen Sprachen kompilierte WASM-Module konnten nicht miteinander kommunizieren, ohne manuelle, fehleranfällige Speicherverwaltung. Eine Rust-Bibliothek und ein Go-Dienst lebten in getrennten Speicherbereichen und teilten kein Typsystem. Das machte komponierbare Polyglott-Architekturen unpraktikabel.

Das WebAssembly Component Model, 2025 stabilisiert, löst dies mit einer gemeinsamen Application Binary Interface und einer sprachunabhängigen Interface-Beschreibungssprache namens WIT (WebAssembly Interface Types). Eine WIT-Datei deklariert, welche Funktionen und Datentypen ein Component exportiert oder importiert – ohne sprachspezifische Speicherannahmen. Die Toolchain – wit-bindgen, wasm-tools, jco – generiert die Integrations-Code automatisch. Das praktische Ergebnis: Ein performanter Rust-Parser, eine Python-ML-Pipeline und ein TypeScript-Frontend können als WASM-Components zusammenspielen, ohne handgeschriebenes FFI. WASM 3.0 wurde im September 2025 als W3C-Standard ratifiziert und integriert Garbage Collection, 64-Bit-Speicher, relaxed SIMD und Exception Handling neben dem Component Model.

WASI: Die Interface-Schicht, die Portabilität real macht

Um WASM außerhalb des Browsers auszuführen, braucht das Modul eine Möglichkeit, mit dem Host-System zu interagieren – Dateien lesen, Netzwerk-Sockets öffnen, auf Standardausgabe schreiben. Das WebAssembly System Interface (WASI) definiert diese APIs in einem capability-basierten Sicherheitsmodell: Ein Modul erhält nur den Zugriff, der ihm bei der Instanziierung explizit gewährt wird. Nichts anderes ist erreichbar.

WASI 0.2, veröffentlicht im Januar 2024, legte die stabile Produktionsbasis fest – Datei-I/O, Netzwerk-Sockets und Integration ins Component Model. WASI 0.3, das native Async-Unterstützung mit typisierten Stream- und Future-Primitiven hinzufügt, war Anfang 2026 in der Spezifikationsarbeit. Version 1.0 – die erste „stabil für immer“-Version – wird für Ende 2026 oder Anfang 2027 erwartet. Die Entwicklung gibt Bibliotheksautoren eine stabile ABI und Betreibern eine klare Roadmap, welche Portabilitätsgarantien langfristig abgedeckt werden.

Wo Produktionsdeployments bereits existieren

Der konkreteste großflächige Beleg ist Shopify Functions. Seit 2022 ermöglicht Shopify Drittanbietern, Checkout-, Rabatt- und Versandlogik zu individualisieren, indem sie WASM-Module deployen, die in einer eigens entwickelten Runtime in Shopifys Infrastruktur laufen. Jedes Modul hat ein striktes 5-Millisekunden-Budget; die gemessenen Latenzen liegen typischerweise zwischen 0,8 und 2,5 Millisekunden. Entwickler schreiben in Rust, JavaScript (über Shopifys Javy-Compiler, der eine abgespeckte V8-Engine in ein WASM-Binary packt), Zig oder TinyGo. Die Sicherheitsgrenze zählt: Nicht vertrauenswürdiger Händler-Code läuft in Produktion in Shopify-Skalierung ohne Zugriff auf Host-System-Ressourcen. Bisher gab es keinen Sandbox-Bruch. Seit Juni 2026 ist das alte Scripts-System, das Functions ersetzte, vollständig abgeschaltet.

Auf der Edge-Computing-Seite bietet Fastlys Compute@Edge eine reine WASM-Ausführungsumgebung mit Mikrosekunden-Cold-Starts für Request-Verarbeitung am Netzwerkrand. Cloudflare Workers unterstützt WASM-Module und fügte im Juni 2025 Container-Support für Hybrid-Workloads hinzu. Das bedeutendste Branchensignal kam Ende 2025, als Akamai Fermyon übernahm – das Unternehmen hinter dem Spin-Framework für serverlose WASM-Microservices – und Fermyon Wasm Functions im November 2025 auf Akamais global verteilter Edge allgemein verfügbar machte. Wenn das größte CDN der Welt ein WASM-Serverless-Unternehmen kauft, ist die Wette auf die Zukunft der Technologie institutionell, nicht experimentell.

Die Runtime-Landschaft

Vier Runtimes dominieren je nach Anwendungsfall. Wasmtime, die Referenzimplementierung der Bytecode Alliance, erreichte im April 2025 den Core Project-Status und liefert etwa 82 % der nativen Performance bei Compute-Benchmarks. Es ist die Default-Wahl für universellen serverseitigen WASM-Einsatz. Wasmer 6.0, veröffentlicht im April 2025, beansprucht 95 % native Performance und führte Edge.js ein, das Node.js-Anwendungen in einer WASM-Sandbox ausführt – eine interessante Brücke für Teams mit bestehender Node-Infrastruktur. WAMR (WebAssembly Micro Runtime) zielt auf Embedded- und IoT-Geräte und läuft auf Hardware mit nur 256 Kilobyte Speicher bei 80 bis 90 % nativer Performance mit AOT-Kompilierung. WasmEdge ist für KI-Workloads optimiert und integriert sich neben Wasmtime als Container-Shim in die Docker Engine.

Dockers Rahmung ist bewusst: „WASM und Container“, nicht „WASM versus Container“. Die Docker Engine liefert native Shims für Wasmtime und WasmEdge, sodass WASM-Module mit standardmäßigen docker run-Befehlen aus einem Scratch-Dockerfile deployt werden können. Die Toolchain konvergiert, statt zu konkurrieren. SpinKube, ein CNCF-Projekt, das auf Fermyons Spin-Framework aufbaut, macht WASM zu einem erstklassigen Workload-Typ in Kubernetes – deploybar neben Container-Pods mit denselben Orchestrierungs-Primitiven.

Das Sicherheitsargument

Das WASM-Sicherheitsmodell ist „deny by default“ auf Binary-Ebene. Ein Modul hat keinerlei Zugriff auf das Host-System, es sei denn, der Host erteilt explizit eine bestimmte Capability bei der Instanziierung. Das unterscheidet sich architektonisch von Containern, die den Host-Kernel teilen und sich auf Namespace- und Cgroup-Isolation verlassen, um den Zugriff eines Workloads zu begrenzen. Bei WASM wird die Sandbox in der Runtime erzwungen, unabhängig von der Sprache, aus der das Modul kompiliert wurde.

Für Multi-Tenant-Plattformen – das Shopify-Modell, bei dem Hunderttausende Händler eigenen Code deployen – ist dies das Feature, das die Architektur tragfähig macht. Die Alternative wäre, jeden Drittanbieter-Code vor dem Deployment zu prüfen, was in großem Maßstab nicht machbar ist. Die WASM-Sandbox eliminiert die Risikokategorie, anstatt sie zu verwalten.

Das ehrliche Performance-Bild

WASM auf serverseitigen Runtimes erreicht etwa 75 bis 95 % der nativen Geschwindigkeit bei rechenintensiven Workloads – glaubwürdige Zahlen für die meisten Anwendungsfälle, mit Einschränkungen. Operationen mit 128-Bit-Integern und bestimmte kryptografische Primitive sind 2- bis 7-mal langsamer als nativ. I/O-lastige Workloads profitieren nicht nennenswert; der Vorteil liegt bei der Rechenleistung. Cold-Starts liegen bei 1 bis 5 Millisekunden, verglichen mit 50 bis 500 Millisekunden für Container – das ist die Kennzahl, die WASM für serverlose und Edge-Deployments attraktiv macht, wo Cold-Start-Latenz die Nutzererfahrung direkt beeinflusst.

Die Entwicklungszeit ist tatsächlich länger. In Rust für WASM zu entwickeln erfordert Verständnis der Speicherverwaltung und eines anderen Debugging-Workflows, als die meisten Webentwickler gewohnt sind. Das Component Model und die WASI-Toolchain haben sich deutlich verbessert, aber das Debugging über Sprachgrenzen hinweg bleibt schwieriger als das Debugging innerhalb eines einzigen Sprach-Stacks. Das Ökosystem befindet sich in etwa dort, wo JavaScript in den frühen Node.js-Jahren war: leistungsstark, produktiv und erfordert Investitionen, um es gut zu nutzen.

Die Frage „Soll ich WASM statt Containern nutzen?“ hat 2026 eine klarere Antwort als vor zwei Jahren: Nutze WASM, wenn Cold-Start-Latenz zählt (Edge und Serverless), wenn du sandboxed Ausführung von nicht vertrauenswürdigem Code brauchst oder wenn du sprachunabhängige Component-Komposition möchtest. Nutze Container, wenn du eine vollständige Linux-Umgebung, breite Bibliothekskompatibilität oder GPU-Zugriff benötigst. Nutze beide, wenn dein Workload Schichten hat, die von beiden profitieren – und genau darauf ist die Infrastruktur-Tooling zunehmend ausgelegt.