WebAssembly Architektur-Guide: Toolchains, Runtimes und Deployment

WebAssembly hat sich von einem Browser-Feature zu einer ernstzunehmenden Deployment-Option entwickelt. Was 2017 als Möglichkeit begann, rechenintensive Anwendungen im Browser auszuführen, ist heute eine portable Laufzeitumgebung für Server, Edge und eingebettete Systeme.

Dieser Guide richtet sich an Architekten und Senior-Entwickler, die WebAssembly systematisch evaluieren wollen. Er beantwortet die zentralen Fragen: Welche Sprachen eignen sich für welche Szenarien? Welche Runtimes sind produktionsreif? Wie funktioniert WASI als Betriebssystem-Schnittstelle? Und wann ist Wasm die bessere Wahl gegenüber Containern?

Das WebAssembly-Ökosystem im Überblick

Bevor wir in die Details einsteigen, hilft ein Blick auf das Gesamtbild. WebAssembly ist ein Kompilierungsziel, kein Framework. Das bedeutet: Entwickler schreiben Code in ihrer bevorzugten Sprache, der Compiler erzeugt ein portables Binary, und eine Runtime führt es aus.

Diese Architektur erklärt, warum WebAssembly so flexibel ist: Das gleiche Binary läuft im Browser, auf einem Linux-Server und auf einem Edge-Node – vorausgesetzt, die verwendeten System-Interfaces sind kompatibel.

Toolchains nach Sprache

Die Wahl der Sprache bestimmt nicht nur die Entwicklererfahrung, sondern auch Binary-Größe, Performance-Charakteristik und verfügbare Bibliotheken. Jede Sprache bringt ihre eigene Toolchain mit, die unterschiedlich ausgereift ist.

Rust

Rust hat sich als bevorzugte Sprache für WebAssembly etabliert. Die Kombination aus Speichersicherheit ohne Garbage Collector und Zero-Cost-Abstractions passt ideal zum Wasm-Modell. Mozilla, einer der Wasm-Initiatoren, hat Rust von Anfang an als primäre Sprache positioniert.

Die Toolchain ist stabil und gut dokumentiert. wasm-pack vereinfacht die Integration in JavaScript-Projekte erheblich, während wasm-bindgen die Brücke zwischen Rust-Typen und JavaScript-Objekten schlägt.

Tooling:

• rustc mit Target wasm32-unknown-unknown (Browser) oder wasm32-wasi (WASI)
• wasm-pack für npm-kompatible Packages
• wasm-bindgen für JavaScript-Interoperabilität
• cargo-component für WASI Component Model

Stärken:

• Kleine Binaries durch Zero-Cost-Abstractions
• Keine Garbage Collection, kein Runtime-Overhead
• Exzellente Fehlerbehandlung mit Result-Typen
• Große Community und viele Wasm-optimierte Crates

Einschränkungen:

• Steile Lernkurve für Rust-Neulinge
• Async-Support in Wasm noch nicht vollständig

# Browser-Target
rustup target add wasm32-unknown-unknown
cargo build --target wasm32-unknown-unknown --release

# WASI-Target
rustup target add wasm32-wasi
cargo build --target wasm32-wasi --release

Ein optimiertes Hello-World-Binary kommt auf etwa 2 KB. In der Praxis liegen typische Module zwischen 50 KB und 500 KB – ein Bruchteil dessen, was Container mitbringen.

Go

Go unterstützt WebAssembly seit Version 1.11. Der Vorteil liegt auf der Hand: Viele Backend-Teams arbeiten bereits mit Go und können ihre Expertise direkt nutzen. Allerdings bringt Go seinen Garbage Collector mit, was die Binary-Größe erhöht.

Hier kommt TinyGo ins Spiel. Diese alternative Go-Implementierung ist speziell für eingebettete Systeme und WebAssembly optimiert. TinyGo produziert deutlich kleinere Binaries und unterstützt WASI nativ.

Tooling:

• Native Go-Compiler mit GOOS=js GOARCH=wasm (Browser)
• TinyGo für kleinere Binaries und WASI-Support
• wazero als reine Go-Runtime

Stärken:

• Vertraute Sprache für Backend-Entwickler
• Goroutines funktionieren (mit Einschränkungen)
• TinyGo produziert deutlich kleinere Binaries

Einschränkungen:

• Standard-Go-Compiler erzeugt große Binaries (mehrere MB)
• Garbage Collector läuft im Wasm-Modul mit
• Nicht alle Standardbibliotheken sind Wasm-kompatibel

# Standard Go (Browser)
GOOS=js GOARCH=wasm go build -o main.wasm

# TinyGo (WASI)
tinygo build -target=wasi -o main.wasm main.go

Der Unterschied ist dramatisch: Standard-Go produziert Binaries um 2 MB, TinyGo kommt auf etwa 50 KB. Für Edge-Szenarien mit strikten Größenlimits ist TinyGo oft die einzige Option.

C/C++

Die älteste Wasm-Toolchain entstand aus dem Bedarf, bestehende C/C++-Codebases in den Browser zu bringen. Emscripten, ursprünglich für asm.js entwickelt, wurde zum WebAssembly-Compiler erweitert.

Große Anwendungen wie Figma, AutoCAD Web und Google Earth nutzen diesen Weg. Sie portieren jahrzehntealten, hochoptimierten Code, statt ihn neu zu schreiben. Das ist der Hauptanwendungsfall: Migration, nicht Neuentwicklung.

Tooling:

• Emscripten (emcc) für Browser mit JavaScript-Glue-Code
• Clang/LLVM mit wasm32-Target für reines Wasm
• wasi-sdk für WASI-kompatible Builds

Stärken:

• Portierung großer bestehender Codebases (Figma, AutoCAD)
• Maximale Kontrolle über Speicher
• Zugang zu C-Bibliotheken

Einschränkungen:

• Komplexes Build-Setup
• Speichersicherheit liegt beim Entwickler
• Emscripten-Output kann groß werden

# Emscripten (Browser)
emcc main.c -o main.js -s WASM=1

# wasi-sdk (WASI)
/opt/wasi-sdk/bin/clang main.c -o main.wasm

Die Binary-Größe variiert stark. Ein minimales Programm kann unter 1 KB liegen, aber sobald Standardbibliotheken oder komplexe Dependencies hinzukommen, wächst das Binary schnell.

AssemblyScript

AssemblyScript verfolgt einen anderen Ansatz: Eine TypeScript-ähnliche Syntax, die direkt zu WebAssembly kompiliert. Für JavaScript-Entwickler ist der Einstieg damit deutlich einfacher als bei Rust oder C++.

Allerdings ist AssemblyScript kein TypeScript. Es sieht ähnlich aus, hat aber eigene Regeln. Der Typ i32 existiert in TypeScript nicht, und viele JavaScript-Idiome funktionieren nicht. Teams müssen sich auf eine neue Sprache einlassen, die nur vertraut aussieht.

Tooling:

• asc Compiler
• Direkte Integration in npm-Workflows

Stärken:

• Vertraute Syntax für Web-Entwickler
• Gute IDE-Unterstützung
• Schneller Einstieg

Einschränkungen:

• Kein vollständiges TypeScript, eigene Sprache
• Weniger Ökosystem als Rust
• Garbage Collection im Wasm-Modul

npm install --save-dev assemblyscript
npx asc assembly/index.ts -o build/module.wasm

Für einfache Module erreicht AssemblyScript Binary-Größen zwischen 1 und 10 KB. Das macht es attraktiv für kleine, fokussierte Funktionen.

Vergleichsmatrix Toolchains

Die Wahl hängt vom Kontext ab. Für neue Projekte mit Performance-Anforderungen ist Rust die sicherste Wahl. Für Teams mit Go-Erfahrung ist TinyGo ein pragmatischer Einstieg. C/C++ bleibt relevant für Portierungen. AssemblyScript eignet sich für Prototypen und einfache Module.

Runtimes im Detail

Eine Wasm-Binary allein macht noch keine Anwendung. Sie braucht eine Runtime, die den Bytecode ausführt und System-Interfaces bereitstellt. Die Wahl der Runtime bestimmt, wo und wie das Modul läuft.

Wasmtime

Wasmtime ist die Referenz-Runtime der Bytecode Alliance, einem Konsortium aus Mozilla, Fastly, Intel, Microsoft und anderen. Sie setzt den Standard für WASI-Kompatibilität und das Component Model.

Der Cranelift-Compiler übersetzt Wasm-Bytecode in nativen Maschinencode. Das passiert beim ersten Aufruf (JIT) oder vorab (AOT). Nach der Kompilierung erreicht Wasmtime nahezu native Performance.

Eigenschaften:

• Cranelift JIT-Compiler für schnelle Ausführung
• Vollständige WASI-Implementierung
• Component Model Support
• Fuel-basierte Ausführungslimits

Einsatzgebiete:

• Server-seitige Wasm-Ausführung
• Embedding in eigene Anwendungen
• CI/CD-Pipelines

# Installation
curl https://wasmtime.dev/install.sh -sSf | bash

# Ausführung
wasmtime run --dir=. module.wasm

# Mit Fuel-Limit
wasmtime run --fuel 10000 module.wasm

Fuel-Limits sind besonders interessant für Multi-Tenant-Szenarien: Sie begrenzen die CPU-Zeit pro Modul, ohne auf OS-Level-Mechanismen zurückgreifen zu müssen.

Wasmer

Wasmer positioniert sich als universelle Runtime mit Fokus auf Embedding. Drei Compiler-Backends stehen zur Wahl: Cranelift für ausgewogene Performance, LLVM für maximale Optimierung, Singlepass für minimale Cold-Start-Zeit.

Ein Alleinstellungsmerkmal ist WAPM, eine Package-Registry für Wasm-Module. Entwickler können Module veröffentlichen und andere können sie direkt ausführen – ähnlich wie npm für JavaScript.

Eigenschaften:

• Mehrere Compiler-Backends (Cranelift, LLVM, Singlepass)
• WAPM Package Registry
• Headless Mode für minimale Dependencies
• iOS und Android Support

Einsatzgebiete:

• Plugin-Systeme
• Mobile Anwendungen
• Package-Distribution über WAPM

# Installation
curl https://get.wasmer.io -sSfL | sh

# Ausführung
wasmer run module.wasm

# Package aus Registry
wasmer run cowsay

Der Singlepass-Compiler ist besonders für Serverless interessant: Er kompiliert in einem Durchgang ohne Optimierung, was die Cold-Start-Zeit minimiert.

WasmEdge

WasmEdge ist ein CNCF-Projekt mit klarem Fokus auf Cloud-Native-Szenarien. Die Integration in Kubernetes über containerd macht Wasm zu einem First-Class-Citizen in Container-Orchestrierung.

Ahead-of-Time-Kompilierung erzeugt native Shared Libraries, die ohne JIT-Overhead starten. Für Edge-Devices mit begrenzten Ressourcen ist das ein entscheidender Vorteil.

Eigenschaften:

• Optimiert für Kubernetes-Integration
• Ahead-of-Time Compilation
• Networking und Sockets über WASI
• TensorFlow-Integration für ML-Workloads

Einsatzgebiete:

• Kubernetes Sidecars
• Edge-Devices
• Serverless Functions

# Installation
curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash

# AOT-Kompilierung
wasmedgec module.wasm module.so

# Ausführung
wasmedge module.wasm

Die containerd-Integration ermöglicht es, Wasm-Module wie Container zu deployen. Kubernetes behandelt sie als Pods, aber mit den Vorteilen von Wasm: schnellerer Start, geringerer Speicherverbrauch.

Browser-Runtimes

Alle modernen Browser enthalten WebAssembly-Runtimes, die für interaktive Anwendungen optimiert sind. Sie bieten die beste JavaScript-Interoperabilität, aber keinen WASI-Support.

• V8 (Chrome, Edge, Node.js): TurboFan und Liftoff Compiler
• SpiderMonkey (Firefox): Baseline und Ion Compiler
• JavaScriptCore (Safari): BBQ und OMG Compiler

Die Browser-Runtimes sind hochoptimiert für schnelle Kompilierung und effiziente Ausführung. Sie profitieren von jahrelanger JavaScript-Optimierung, die auf Wasm übertragen wurde.

Vergleichsmatrix Runtimes

Für Server-Workloads ist Wasmtime die konservative Wahl. Für Kubernetes-Integration führt kein Weg an WasmEdge vorbei. Wasmer glänzt bei Plugin-Systemen und Package-Distribution.

WASI: Das Betriebssystem-Interface

WebAssembly im Browser interagiert mit JavaScript. Aber was ist mit Server-Anwendungen, die Dateien lesen oder Netzwerkverbindungen öffnen wollen? Hier kommt WASI ins Spiel.

WASI (WebAssembly System Interface) definiert, wie Wasm-Module mit der Außenwelt interagieren. Es ist das fehlende Stück zwischen portablem Bytecode und realen Anwendungen – eine standardisierte API für Systemaufrufe.

WASI Preview 1

Die aktuelle stabile Version bietet grundlegende Systemzugriffe. Sie deckt die häufigsten Anforderungen ab: Dateisystem, Umgebungsvariablen, Kommandozeilenargumente.

• Dateisystem: Lesen, Schreiben, Verzeichnisse (capability-basiert)
• Umgebungsvariablen: Zugriff auf Environment
• Argumente: Kommandozeilenparameter
• Uhrzeit: Monotone und Echtzeit-Uhren
• Zufallszahlen: Kryptografisch sichere Zufallsquelle

use std::fs;
use std::env;

fn main() {
    // Dateizugriff nur auf explizit freigegebene Verzeichnisse
    let content = fs::read_to_string("/data/config.json").unwrap();
    
    // Umgebungsvariablen
    let api_key = env::var("API_KEY").unwrap_or_default();
}

Wichtig ist das Capability-Modell: Das Modul hat keinen impliziten Zugriff auf das Dateisystem. Die Runtime muss Verzeichnisse explizit freigeben.

WASI Preview 2 und Component Model

Die nächste Generation bringt fundamentale Erweiterungen. Das Component Model ermöglicht es, Wasm-Module zu komponieren – ein Modul kann Funktionen aus einem anderen importieren, ohne den Umweg über JavaScript.

• Komponenten: Wasm-Module können andere Module importieren
• Interface Types: Typsichere Kommunikation zwischen Komponenten
• Async: Natives async/await
• Sockets: Netzwerk-Support (Preview 2)

// WIT (WebAssembly Interface Types) Definition
package example:http;

interface handler {
    record request {
        method: string,
        path: string,
        body: list[u8],
    }
    
    record response {
        status: u16,
        body: list[u8],
    }
    
    handle: func(req: request) -> response;
}

WIT (WebAssembly Interface Types) ist die Schnittstellenbeschreibungssprache für Komponenten. Sie definiert, welche Typen und Funktionen ein Modul exportiert oder importiert.

Capability-basierte Sicherheit

WASI implementiert ein Capability-Modell, das sich fundamental von Container-Sicherheit unterscheidet. Bei Containern muss man Zugriffe einschränken (Default: alles erlaubt). Bei WASI muss man sie freigeben (Default: nichts erlaubt).

# Nur Lesezugriff auf /data
wasmtime run --dir=/data::readonly module.wasm

# Lesend und schreibend
wasmtime run --dir=/data module.wasm

# Netzwerk (mit WASI Preview 2)
wasmtime run --tcplisten=127.0.0.1:8080 module.wasm

Dieses Modell macht die Angriffsfläche explizit. Ein Modul kann nur auf das zugreifen, was ihm ausdrücklich gewährt wurde. Für sicherheitskritische Anwendungen ist das ein erheblicher Vorteil.

Deployment-Optionen

WebAssembly läuft überall – aber die Deployment-Strategien unterscheiden sich erheblich. Edge-Plattformen, Server-Infrastruktur und Browser haben jeweils eigene Anforderungen und Tooling.

Edge-Plattformen

Edge-Computing ist der natürliche Lebensraum für WebAssembly. Die Kombination aus schnellem Start, kleinen Binaries und Isolation passt perfekt zu den Anforderungen globaler Verteilung.

Cloudflare Workers nutzt V8 Isolates, die in Millisekunden starten. Wasm-Module werden zusammen mit JavaScript deployed und teilen sich die Isolate-Infrastruktur.

// wrangler.toml
[build.upload]
format = "modules"
main = "./worker.mjs"

[[build.upload.rules]]
type = "CompiledWasm"
globs = ["**/*.wasm"]

Fastly Compute setzt auf eine eigene Wasmtime-basierte Runtime. Der Vorteil: Native WASI-Unterstützung und dedizierte SDKs für Rust, Go und JavaScript.

Vercel Edge Functions integriert Wasm als Teil des Edge-Function-Modells. Die enge Verzahnung mit Next.js macht es für React-Projekte attraktiv.

Server-Deployment

Auf eigener Infrastruktur gibt es mehrere Optionen. Die einfachste ist ein Systemd-Service, der Wasmtime als Prozess startet.

# Systemd Service
[Unit]
Description=Wasm Service

[Service]
ExecStart=/usr/bin/wasmtime run --dir=/data /opt/app/service.wasm
Restart=always

[Install]
WantedBy=multi-user.target

Für Kubernetes-Umgebungen bietet WasmEdge eine containerd-Integration. Wasm-Module werden als Container-Images verpackt und wie normale Pods deployed.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    module.wasm.image/variant: compat-smart
spec:
  runtimeClassName: wasmtime
  containers:
  - name: wasm-app
    image: ghcr.io/example/app:latest

Die Kubernetes-Integration ist noch jung, aber sie zeigt die Richtung: Wasm als Alternative zu Containern, nicht als Ersatz.

Browser-Deployment

Im Browser ist Wasm am längsten etabliert. Die APIs sind stabil und gut dokumentiert.

// Modernes Laden mit Streaming
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/module.wasm'),
  importObject
);

// Mit wasm-bindgen (Rust)
import init, { process_data } from './pkg/module.js';
await init();
const result = process_data(input);

Streaming-Kompilierung ist wichtig für größere Module: Der Browser beginnt mit der Kompilierung, während das Binary noch heruntergeladen wird.

Deployment-Vergleich

Edge-Plattformen bieten die beste Developer Experience für einfache Use-Cases. Kubernetes-Integration macht Sinn für Teams, die bereits Container orchestrieren. Standalone-Deployment ist für spezialisierte Workloads oder On-Premise-Szenarien relevant.

Entscheidungsrahmen: Wasm vs. Container

Die Frage ist nicht, ob WebAssembly Container ersetzt – sondern wann welche Technologie besser passt. Beide haben ihre Stärken, und gute Architekturen nutzen oft beide.

Wann WebAssembly wählen

WebAssembly glänzt bei klar abgegrenzten, stateless Funktionen, die schnell starten müssen. Die Security-Isolation durch das Capability-Modell ist ein Bonus für Multi-Tenant-Szenarien.

Starke Indikatoren:

• Startzeit unter 100ms erforderlich
• Ausführung auf Edge/CDN gewünscht
• Security-Isolation kritisch
• Artefaktgröße muss klein bleiben
• Klar abgegrenzte, stateless Funktionen

Typische Anwendungsfälle:

• Request-Filterung und -Transformation
• Authentifizierung und Autorisierung
• Bildverarbeitung
• Datenvalidierung
• Plugins und Extensions

Wann Container wählen

Container bleiben die richtige Wahl für komplexe Anwendungen mit vielen Dependencies, stateful Workloads und Szenarien, die volle OS-Funktionalität brauchen.

Starke Indikatoren:

• Komplexe native Dependencies
• Stateful Workloads
• Bestehende Container-Infrastruktur
• Volle OS-Funktionalität benötigt
• Datenbank-Anbindung

Typische Anwendungsfälle:

• API-Server mit Datenbankzugriff
• Hintergrund-Worker
• Legacy-Anwendungen
• ML-Training (GPU-Zugriff)

Hybride Architekturen

In der Praxis ergänzen sich beide Technologien. Eine typische Architektur nutzt Wasm für Edge-Logik und Container für Backend-Services.

Diese Architektur kombiniert die Stärken beider Welten: Schnelle, globale Edge-Logik in Wasm und robuste Backend-Services in Containern.

Performance-Überlegungen

Performance ist einer der Hauptgründe für WebAssembly. Aber die Realität ist differenzierter als die Marketing-Versprechen.

Startup-Zeit

Der größte Vorteil von Wasm liegt in der Startup-Zeit. Während Container Sekunden brauchen, starten Wasm-Module in Millisekunden.

Für Serverless-Szenarien mit vielen Cold-Starts ist das ein entscheidender Unterschied. Für lang laufende Prozesse ist die Startup-Zeit weniger relevant.

Speicherverbrauch

Wasm-Module haben einen deutlich geringeren Speicher-Overhead als Container. Sie bringen kein Betriebssystem mit, keine redundanten Bibliotheken, nur den Anwendungscode.

• Container: 50-500 MB Baseline
• Wasm-Modul: 1-50 MB je nach Anwendung

Die lineare Speicheradressierung von Wasm ist effizient, aber begrenzt. Für speicherintensive Workloads kann das zum Nachteil werden.

Durchsatz

Bei rechenintensiven Aufgaben erreicht Wasm 80-95% der nativen Performance. Der Overhead entsteht durch Bounds-Checking bei Speicherzugriffen und indirekte Funktionsaufrufe.

SIMD-Unterstützung verbessert sich kontinuierlich. Moderne Runtimes nutzen SIMD-Instruktionen für Vektoroperationen, was die Lücke zur nativen Performance weiter schließt.

Migration bestehender Anwendungen

Die Migration zu WebAssembly ist kein Alles-oder-Nichts-Projekt. Ein schrittweiser Ansatz minimiert Risiken und liefert früh Ergebnisse.

Schritt 1: Kandidaten identifizieren

Nicht jeder Code eignet sich für Wasm. Gute Kandidaten sind stateless, CPU-intensiv und haben wenige externe Dependencies.

Gute Kandidaten:

• Stateless Request-Handler
• CPU-intensive Berechnungen
• Isolierte Bibliotheken
• Validierungslogik

Schlechte Kandidaten:

• Datenbankzugriff
• Dateisystem-intensive Operationen
• Komplexe native Dependencies

Schritt 2: Sprache wählen

Die Sprachwahl hängt vom Team und vom Anwendungsfall ab.

Für Neuimplementierung:

• Rust bei Performance-Kritikalität
• Go/TinyGo bei bestehendem Go-Know-how
• AssemblyScript für schnelle Prototypen

Für Portierung:

• C/C++ mit Emscripten für bestehenden Code
• Rust für sicherheitskritische Neuschreibung

Schritt 3: Runtime wählen

Die Runtime-Wahl folgt dem Deployment-Ziel.

• Browser: Native Browser-Runtime
• Edge: Plattform-spezifisch (Cloudflare, Fastly)
• Server: Wasmtime für Stabilität, WasmEdge für Kubernetes

Schritt 4: Schrittweise einführen

1. Einzelne Funktion als Wasm-Modul implementieren
2. Parallel zum bestehenden Code betreiben
3. Performance und Korrektheit validieren
4. Schrittweise Traffic umleiten
5. Weitere Funktionen migrieren

Der parallele Betrieb ist entscheidend. Er ermöglicht A/B-Tests und schnelles Rollback, falls Probleme auftreten.

WebAssembly systematisch lernen

Sie möchten WebAssembly von Grund auf verstehen und produktionsreife Architekturen aufbauen?

👉 WebAssembly lernen – Der komplette Praxis-Kurs

Im Kurs lernen Sie:

• WebAssembly Grundlagen und Konzepte
• Rust + WASM Toolchain Setup und Workflow
• Praktische Integration in Web-Projekte
• Performance-Optimierung und Debugging
• Browser APIs und DOM-Manipulation mit Rust
• Deployment und Best Practices

Weiterführende Ressourcen

• WebAssembly Specification
• WASI Proposals
• Bytecode Alliance
• Wasmtime Documentation
• Rust and WebAssembly Book

Verwandte Artikel

• Container oder WebAssembly? Eine Architekturentscheidung – Strategische Abwägung zwischen beiden Technologien
• Rust + WebAssembly: Einstieg für Webentwickler – Praktischer Einstieg in die Wasm-Entwicklung

Realistische WASM-Performance

• Image-Processing: 2–10x schneller als JS.
• Cryptography: 3–8x schneller.
• Numerische Berechnungen: 5–20x schneller.
• DOM-Manipulation: WASM ist nicht direkt — Bridge zu JS nötig, kostet Performance.

Wann WASM Sinn macht

• CPU-intensive Berechnungen im Browser.
• Spiel-Engines (Unity, Godot Web-Export).
• Existing C++/Rust-Code im Browser.
• Edge-Computing mit Wasmtime/Wasmer.

Wann nicht WASM

• Standard-Web-Apps: Kein Mehrwert.
• UI-Komponenten: JS einfacher.
• Apps mit kleinem JS-Bundle: WASM-Overhead nicht gerechtfertigt.

Aktueller Stand 2026

• Browser-Support: Vollständig in allen modernen Browsern.
• WASI: Server-side WASM, im Aufbau (Wasmtime, Wasmer).
• Components Model: Neue Architektur für WASM-Komponenten, in Entwicklung.