WebAssembly · for Java developers

WebAssembly, without the hand-waving.

You've shipped to the JVM for years. WebAssembly (WASM) is how your code reaches the places the JVM can't — the browser, the edge, a Node process — as a small, fast, sandboxed binary. Here's what it is and why it matters, in Java terms.

What WASM actually is

It's a compile target, not a language — a portable binary instruction format that runs at near-native speed inside a tiny runtime (a "WASM engine") embedded in a host: a browser, a server, an edge worker. You compile to it, the way you compile Java to bytecode.

It's sandboxed by default. A module can't touch the filesystem, network, or OS unless the host explicitly hands it a function to do so. Memory-safe, isolated — closer to a locked-down applet than a process.

WASM-GC (shipped in browsers and Node through 2024) added a garbage collector to the spec. That's the unlock for managed languages: before it, Java/Kotlin had to compile their own GC into the module (huge, slow); with WASM-GC they use the host's collector — so a Java event processor becomes a compact module.

In Java terms
  • ▸ Like a GraalVM native image — but the artifact runs inside a sandbox you can embed anywhere, including a browser tab.
  • ▸ Like a jar you can run with no JVM installed.
  • ▸ The host (browser / edge / Node) plays the JVM's role: it loads the module and calls in; the module calls out only through functions the host provides.

Where it runs

  • The browser its original home — Figma, Photoshop Web, games, and now business logic running client-side at near-native speed
  • Edge / CDN compute Cloudflare Workers, Fastly Compute — modules run milliseconds from the user, with no JVM to warm up
  • Serverless fast-cold-start functions where a JVM container would be too heavy
  • Plugin / extension systems Envoy filters, Shopify Functions, in-database UDFs — untrusted code run safely, in-process

The common thread: somewhere you want to run real logic without shipping a JVM or a container — fast to start, safe to embed, the same everywhere.

Why a Java developer should care

You can take logic you wrote, tested, and trust in Java — and run it where the JVM was never an option: the user's browser, a CDN edge node, a Node service — with millisecond start, no container, no JVM, sandboxed and deterministic. Not a rewrite in JavaScript; the same compiled logic.

How Java reaches WASM

A compiler — TeaVM is the one used here — turns Java bytecode into a WASM-GC module ahead of time. No JVM ships with it; the module is self-contained logic.

Honest about the edges: it's a sandbox + an ahead-of-time, closed world. Reflection, threads, arbitrary I/O, and some libraries don't translate directly — they need metadata or a different approach. Pure compute and event logic translate cleanly.

Where Fluxtion fits

A Fluxtion event processor is an ideal WASM citizen: deterministic, single-threaded, no I/O in its core (the host feeds it events), and AOT-compiled with no runtime reflection — exactly the shape WASM wants. Author and test it in Java, compile to WASM, run it in the browser or at the edge.

See Fluxtion in WASM — the live demos + benchmark →

Worth knowing

  • 🌐 WASM-GC is new — recent Chrome / Firefox / Safari, Node 20+. Older environments don't have it.
  • 🔒 It's a sandbox — no direct OS access; the host mediates everything. That's the security model, and the constraint.
  • 🎯 It's a deployment target for the right code, not a JVM replacement.