WebAssembly in 2026: Where It Has Landed, What WASI 0.2 Changes, and Why Java and Kotlin Developers Should Pay Attention Now

WebAssembly has moved from browser novelty to a legitimate server-side runtime. WASI 0.2 introduced the Component Model and a proper interface type system. Java’s TeaVM and Kotlin/Wasm allow JVM-adjacent code to compile to Wasm. Here is the honest state of all three in 2026.

Back in 2019, Solomon Hykes’ famous tweet — “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker” — lit up every tech forum on the internet. It was a bold claim. Seven years on, it still has not fully come true. However, the gap between that vision and today’s reality has narrowed considerably. Moreover, for Java and Kotlin developers specifically, 2025 and early 2026 brought a set of changes that make WebAssembly worth understanding for the first time — not as a JavaScript performance trick, but as a genuine deployment target.

This article focuses on three threads: where server-side Wasm actually stands in 2026, what WASI 0.2 (formerly called Preview 2) introduced and why it matters architecturally, and what Java and Kotlin developers can actually compile to Wasm today and where the limits still are.

1. A quick grounding: what WebAssembly actually is

WebAssembly is a binary instruction format for a stack-based virtual machine. That description is deliberately neutral — it says nothing about browsers, servers, or languages. Wasm is a compilation target, not a language. You write in C, Rust, Go, Java, Kotlin, or any of 40+ supported languages, and your toolchain emits a .wasm binary that runs inside a Wasm runtime.

The runtime is a sandboxed execution environment. By default, a Wasm module cannot touch the filesystem, open a network socket, or read environment variables — it can only compute and communicate through explicitly provided imports. That capability-based security model is, in fact, one of the key reasons the cloud industry is paying attention. Furthermore, because Wasm binaries are portable across architectures, the same file runs unchanged on x86_64 and ARM without recompilation.

WebAssembly is not a JVM replacement and is not trying to be. It occupies a different niche: portable, sandboxed, near-native execution with no assumptions about a host OS. Think of it as a universal, secure plugin format that happens to also run servers.

2. The server-side landscape: who is actually running Wasm in production?

The honest answer, as of early 2026, is that server-side Wasm is production-ready for a specific class of workloads — primarily edge functions, FaaS, and plugin systems — and not yet viable for general-purpose microservices. That distinction matters enormously if you are evaluating whether to invest time in this area.

The deployments that are genuinely running at scale share a profile: short-lived, stateless, I/O-light handlers that benefit from sub-millisecond cold starts. Fastly’s Compute@Edge serves over 10,000 active users. Cloudflare Workers handles millions of requests with cold start times measured in microseconds rather than the hundreds of milliseconds typical of containerised functions. Fermyon Spin — notably acquired by Akamai in 2025 — processes roughly 75 million requests per second on their edge platform and joined the CNCF Sandbox, which means Wasm workloads are now schedulable directly via Kubernetes as a containerd shim.

Nobody is running a general-purpose microservices backend on Wasm in production at scale as of early 2026. The deployments that work are edge/CDN platforms, serverless FaaS, and internal tooling. That distinction matters when you are deciding whether to explore this stack now or in 18 months.

Browser WebAssembly usage — % of Chrome page loads

In the browser, the story is even more positive. Chrome Platform Status metrics put Wasm usage at roughly 5.5% of Chrome page loads as of early 2026, up from 4.5% the prior year. Figma’s rendering engine, Adobe Photoshop on the web, AutoCAD Web, and Google Meet’s video processing all run on Wasm. These are billions of page loads weekly. The browser story, in other words, is already a genuine success. Meanwhile, WebAssembly 3.0 became a W3C standard in September 2025, standardising nine production features including WasmGC, exception handling, tail calls, 64-bit memory, and 128-bit SIMD.

3. What WASI 0.2 actually changed — and why it matters

The original WebAssembly spec gave you a fast, sandboxed compute engine with no way to talk to the outside world. WASI (WebAssembly System Interface) was created to fix that. Early WASI — now called WASI 0.1 or WASIp1 — provided basic POSIX-like capabilities: filesystem access, environment variables, clocks, and random numbers. However, it notably lacked networking and had no way to express rich interfaces between modules.

The Bytecode Alliance voted to launch WASI 0.2 (also known as Preview 2 or WASIp2) on January 25, 2024. Wasmtime, Spin, and wasmCloud all fully implement it. It introduced several things that together represent a genuine architectural upgrade, not just a feature increment.

The Component Model

The single biggest addition in WASI 0.2 is the Component Model. Previously, a Wasm module was a monolithic binary with a flat set of imports and exports defined in terms of primitive numeric types — integers and floats, nothing more. Composing modules written in different languages was essentially manual and fragile.

The Component Model introduces a formal type system for inter-module communication. Interfaces are described in WIT (WebAssembly Interface Types), a purpose-built IDL that expresses strings, records, enumerations, options, results, and resource handles. A component that exports a wasi:http/incoming-handler interface can be composed with any other component that imports it, regardless of the language each was written in. In practical terms, this means Wasm modules finally behave like proper LEGO bricks — you can link a Rust component to a Kotlin component to a C component through a well-defined contract, not through C-style ABI hacks.

The Component Model is what makes Wasm interesting beyond “can I run my code in a browser.” It means a JVM language toolchain that produces a valid component can interoperate with the entire Wasm ecosystem — Rust libraries, Python services, whatever — through a typed interface. Language neutrality is not theoretical anymore; it is specified.

What WASI 0.2 added in terms of APIs

Beyond the Component Model, WASI 0.2 expanded the API surface considerably. Specifically, it introduced HTTP client and server support through wasi-http, TCP/UDP socket support via wasi-sockets, key-value store interfaces, and refactored the existing filesystem and clocks interfaces in terms of WIT. This is what finally makes Wasm viable for network-handling server workloads — the previous preview had no way to open a socket at all.

For completeness: WASI 0.3 is in active development, with Fermyon’s Spin v3.5 shipping the first release candidate in November 2025. Its headline feature is native async I/O built into the Component Model, which removes the callback-based workarounds that currently make network I/O feel awkward. When it ships, it will significantly improve ergonomics for server-side workloads. WASI 1.0 — the stable, long-term standard — is planned for 2026.

4. The JVM path to Wasm: what exists and how mature it is

This is the section that most Java and Kotlin developers want to reach — and the one where honest assessment matters most, because the marketing has consistently outrun the tooling. So let us walk through each option clearly.

TeaVM: Java bytecode → Wasm (browser-focused, WASI fork exists)

TeaVM is an ahead-of-time compiler that takes compiled Java bytecode (not source code) and emits JavaScript or WebAssembly. Unlike GWT, which required source code and only targeted JavaScript, TeaVM works at the bytecode level — which means it handles Kotlin and Scala out of the box, since those also compile to JVM bytecode.

TeaVM compiles to WasmGC, the newer WebAssembly standard for garbage-collected languages. This is meaningful: rather than bundling an entire GC implementation inside the Wasm module (a notorious hack used by Go and earlier JVM toolchains), TeaVM delegates to the host engine’s garbage collector. The result is smaller binaries and cleaner memory semantics. As of late 2025, TeaVM is considered production-ready for browser targets. The WebFX project uses it to run JavaFX in browsers via Wasm with live demos.

However, TeaVM’s primary story is still browser-side. For server-side WASI targets, Fermyon maintains a friendly fork called teavm-wasi that adds WASI support and Component Model bindings, published to Maven Central under com.fermyon. This fork is experimental — the official TeaVM team has not yet merged WASI support upstream. Therefore, if you want to target a WASI runtime from Java today, you are working with a community fork, not the mainline project. That is a real caveat for production adoption.

Quickstart: TeaVM + Maven

The following minimal pom.xml snippet shows how to set up TeaVM for WebAssembly in a Maven project. It compiles your Java bytecode to a .wasm binary with no source code transformation required.

<!-- pom.xml snippet for TeaVM WebAssembly output -->
<plugin>
  <groupId>org.teavm</groupId>
  <artifactId>teavm-maven-plugin</artifactId>
  <version>0.10.2</version>
  <executions><execution>
    <goals><goal>compile</goal></goals>
    <configuration>
      <mainClass>com.example.Main</mainClass>
      <targetType>WEBASSEMBLY_GC</targetType>
      <optimizationLevel>ADVANCED</optimizationLevel>
    </configuration>
  </execution></executions>
</plugin>

Kotlin/Wasm: browser Beta, WASI support in progress

JetBrains’ Kotlin/Wasm is the most actively developed JVM-adjacent Wasm toolchain right now. It relies on WasmGC and, as of December 2024, all major browsers including Safari finally support WasmGC — meaning Kotlin/Wasm browser apps now run across 100% of modern browsers. Compose for Web hit Beta in September 2025, and JetBrains’ own benchmarks show it performing nearly three times faster than the equivalent Kotlin/JS build in UI-heavy workloads.

For server-side use, Kotlin/Wasm uses a wasm-wasi target that calls the WASI API directly. This allows Kotlin applications to run outside the browser in any WASI-compatible runtime. However, as of the March 2026 Kotlin roadmap, Kotlin/Wasm is still in Beta overall. The WASI target exists, works for basic use cases, and is documented — but it is not yet recommended for production server workloads. Threading support via the Wasm threads proposal is on the roadmap but not shipped yet.

That said, the velocity here is genuinely impressive. Incremental compilation is now twice as fast as a year ago, output binary sizes are shrinking, and multi-module compilation support (enabling dynamic loading and plugin systems) is in active development. For a Kotlin developer evaluating this stack, the right framing is: the browser story is real and usable today; the server story is 12–18 months from production confidence.

5. How the Component Model changes your architecture

Before the Component Model, composing Wasm modules was a manual, brittle process. Each module had a flat export table of functions with only numeric types. If you wanted a Rust module to call into a Java/TeaVM module, you needed to manually marshal strings into memory offsets and pass raw pointers — the kind of work that belongs in 1990s C interop, not modern systems.

WASI 0.2’s Component Model changes this fundamentally. A WIT interface definition looks like this — and importantly, any toolchain that generates a valid component from it can interoperate with any other:

// A simple WIT interface definition (WebAssembly Interface Types)
package example:processor;

interface transform {
  // Rich types: strings, records, results — not just integers
  record document {
    id: string,
    content: string,
    language: string,
  }

  process: func(doc: document) -> result;
}

world processor {
  export transform;
}

A Kotlin/Wasm component that exports transform and a Rust component that imports it can be composed at the Wasm layer without any intermediate serialisation layer like JSON or protobuf. The Wasm runtime handles the type glue. This is, architecturally, more similar to a microkernel capability system than to a microservices RPC setup — and it is why the Bytecode Alliance describes components as “LEGO bricks.”

Consequently, the practical implication for JVM developers is this: even if you are not ready to write your core business logic in Kotlin/Wasm today, you can start exploring component-based architectures where JVM-compiled components interact with Rust or Go components through well-typed WIT interfaces. The glue layer is finally stable enough to experiment with seriously.

Approximate cold-start latency — serverless function deployment

6. What should Java and Kotlin developers actually do in 2026?

Given all of the above, here is a realistic breakdown of actions worth taking now versus actions worth deferring.

• ✓Learn WIT and the Component Model nowThe interface type system is stable in WASI 0.2 and will not change substantially before 1.0. Understanding how to write a WIT interface and what a component boundary means architecturally is low-cost, high-value learning — especially because this knowledge transfers regardless of which language you write components in.
• ✓Evaluate Kotlin/Wasm for browser UI if you are a Kotlin Multiplatform shopCompose for Web is in Beta and JetBrains considers it production-ready for early adopters. The 3× performance advantage over Kotlin/JS in UI workloads is real and measurable. If you are building a KMP app targeting Android, iOS, desktop, and web, the web target now has a credible story.
• →Prototype edge functions with Fermyon Spin if cold start mattersFor FaaS or edge use cases where sub-millisecond cold start is a real requirement, Wasm is the only viable option today. Spin’s CNCF Sandbox status means it integrates with the Kubernetes toolchain you probably already use. TeaVM’s WASI fork or a Rust/Go component are more practical choices than Kotlin/Wasm for production WASI targets right now.
• Defer migrating server-side Spring/Quarkus workloads to WasmThreading support in WASI is still unresolved. Without it, database connection pools, parallel request handling, and high-throughput I/O are all outside Wasm’s reach. The threading proposal is on the roadmap but has no concrete ship date as of early 2026. Wait for WASI 0.3 to stabilise and for Kotlin/Wasm to reach a stable release before seriously evaluating this path for production backend services.
• ★Watch GraalWasm if you are Oracle-stack alignedGraalVM’s Wasm story is server-focused rather than browser-focused, making it architecturally interesting for JVM shops. Its Java→Wasm compiler is still nascent compared to TeaVM, but Oracle’s backing means it will mature. If you are already invested in GraalVM Native Image, the path to Wasm support from there is a natural evolution to monitor.

7. Why WasmGC is the most important spec feature for JVM developers

Before WasmGC standardised in 2024 and reached full cross-browser support in December 2024 (when Safari finally joined Chrome, Firefox, and Edge), compiling a garbage-collected language to Wasm meant one uncomfortable thing: shipping your entire runtime with the module. The Go team did this for years — every Go Wasm binary includes the Go runtime, resulting in binaries of several megabytes even for trivial programs. JVM-targeting tools used similarly invasive workarounds.

WasmGC fixes this by adding first-class GC types — structs, arrays, references — to the Wasm specification itself. Instead of a JVM shipping its own heap management inside the Wasm module, the module declares typed heap objects and the host engine’s GC manages them natively. The practical benefits are significant: much smaller binaries, better performance for allocation-heavy workloads, and no more manual memory marshalling when crossing language boundaries.

For Java and Kotlin specifically, this is the change that makes Wasm worth revisiting. TeaVM’s WEBASSEMBLY_GC target and Kotlin/Wasm both depend on it. Without WasmGC, neither toolchain could produce binaries that behaved predictably in real workloads. With it, the results — particularly in browser benchmarks — are genuinely encouraging.

8. What we have learned

• WebAssembly is production-ready for edge functions and FaaS in 2026, but general-purpose backend microservices are not yet a realistic target — primarily due to unresolved threading support in WASI.
• WASI 0.2, released January 2024, introduced the Component Model and WIT interface types, plus networking (HTTP and TCP/UDP) — a genuine architectural upgrade that makes inter-language composition formally possible.
• WASI 0.3 is in active development with native async I/O as its headline feature; WASI 1.0 is planned for 2026. WASIp3’s first RC shipped in Spin v3.5 in November 2025.
• WasmGC, now supported by all major browsers including Safari (December 2024), eliminates the need to bundle a full GC runtime inside Wasm modules — a prerequisite for practical JVM-language Wasm toolchains.
• TeaVM compiles Java bytecode (and therefore Kotlin, Scala) to WasmGC and is production-ready for browser targets. A Fermyon-maintained fork adds WASI support experimentally.
• Kotlin/Wasm reached Beta in September 2025. The browser story via Compose for Web is compelling (3× faster than Kotlin/JS in UI benchmarks). The server/WASI story is progressing but not yet production-ready.
• The right 2026 posture for JVM developers: learn WIT now, evaluate Kotlin/Wasm for browser KMP targets, prototype edge functions, and defer production WASI server migration until threading support lands.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.