WebAssembly draait nu op meer servers en edge-nodes dan in browsers, en 67% van de organisaties geeft aan het in productie te gebruiken. De sprong van 47% twee jaar geleden plaatst Wasm midden in de mainstream voor serverless functies en edge-compute workloads.

Hoe de verschuiving plaatsvond

Toen WebAssembly voor het eerst verscheen, was de belofte om browsers een snelle, veilige manier te bieden om code uit te voeren die in andere talen dan JavaScript is geschreven. Vroege gebruikers bouwden games en zware grafische tools, maar de runtime bleef binnen de sandbox van de browser. In de afgelopen jaren heeft een reeks platformverbeteringen — waarvan het Component Model de meest opvallende is — de deur geopend naar integratie tussen verschillende talen, zonder de wrijving die het mixen van Rust, Go of andere talen voorheen een nachtmerrie maakte.

Tegelijkertijd begonnen cloudproviders en CDN's Wasm-gebaseerde executieomgevingen aan te bieden. In 2026 draaien er meer Wasm-workloads op servers en aan de edge dan in browsers.

Wat de cijfers betekenen

  • Cold-start tijd – een nieuwe Wasm-instantie kan in minder dan 10 ms klaar zijn; een typische Docker-container heeft nog steeds enkele seconden nodig om op te starten. Voor request-gestuurde API's vertaalt dit zich direct in de door de gebruiker ervaren latentie.
  • Binair formaat – een Wasm-module is meestal tussen de 2 MB en 5 MB groot. Een vergelijkbare Docker-image weegt vaak tussen de 100 MB en 200 MB, wat belangrijk is voor edge-locaties met beperkte bandbreedte.
  • Veiligheid – het sandboxed executiemodel isoleert onbetrouwbare code, waardoor platforms plugins van derden kunnen draaien naast kerndiensten zonder het host-besturingssysteem bloot te stellen.
  • Draagbaarheid – een enkele Wasm-binary kan draaien op elke host die de specificatie implementeert, ongeacht het onderliggende besturingssysteem of taal-ecosysteem.

Waar Wasm uitblinkt

Het Component Model stelt een module die in de ene taal is geschreven in staat om een goed gedefinieerde interface te bieden die door een andere taal kan worden geïmporteerd. Dit maakt het praktisch om pluginsystemen te bouwen waarbij modules in verschillende talen met elkaar kunnen samenwerken zonder dat er aangepaste glue code nodig is.

Typische scenario's die vandaag de dag profiteren van Wasm zijn onder meer:

  • Edge-functies die HTTP-verzoeken transformeren, authenticatie uitvoeren of lichte AI-inferentie draaien.
  • Plugin- of extensie-architecturen waarbij ontwikkelaars van derden binaries indienen die in een sandbox moeten draaien.
  • Kortstondige, stateless compute zoals het verkleinen van afbeeldingen, datavalidatie of het evalueren van feature flags.

Beperkingen die Docker relevant houden

Wasm is geen universele vervanging voor containers. De sandbox geeft het volledige besturingssysteem niet bloot, wat betekent dat:

  • Langlopende services die een status (state) bijhouden in het geheugen of op de schijf, nog steeds de voorkeur geven aan containers.
  • Applicaties die directe GPU-toegang, gespecialiseerde kernelmodules of diepe integratie op systeemniveau nodig hebben, blijven gebruikmaken van Docker of vergelijkbare runtimes.

Vanwege deze beperkingen gebruiken veel organisaties een hybride stack: Wasm voor de snelle, goedkope edge-laag en containers voor de zware back-end-services.

Waar je op moet letten

  • Volwassenheid van tooling – tools voor debugging, profiling en observability voor Wasm moeten nog steeds inhalen wat het decennia oude Docker-ecosysteem al heeft bereikt.

Conclusie

WebAssembly is veranderd van een curiositeit in de browser naar een essentieel onderdeel van moderne serverless en edge-infrastructuur. De snelheid, de minimale voetafdruk en de ingebouwde isolatie maken het de standaardkeuze voor workloads die direct moeten opstarten en goedkoop aan de edge moeten draaien. Voor de rest — stateful services, GPU-intensieve taken, diepe OS-integratie — behouden containers nog steeds het voordeel.