24 Sep 2025

-

4 min read time

WebAssembly 3.0: What shipped and what remains a proposal

WebAssembly 3.0 is the live standard. See which features shipped—including garbage collection, tail calls and relaxed SIMD—which proposals remain separate, and what to check before using Wasm across browsers and other runtimes.

 Korneliusz Caputa

By Korneliusz Caputa

WebAssembly 3.0: What shipped and what remains a proposal

WebAssembly 3.0: Shipped Features and What Comes Next

WebAssembly 3.0 was announced as the live standard in September 2025. This article distinguishes features included in that release from proposals still progressing separately, then looks at where Wasm can run and what to evaluate before adopting it.

What Shipped in WebAssembly 3.0?

WebAssembly 3.0 includes garbage collection, tail calls, typed function references and relaxed SIMD. Fixed-width SIMD and the original reference types were already part of 2.0; Threads remains a separate Phase 4 proposal. Three of the 3.0 additions are:

  • Relaxed SIMD for vector operations

  • Tail calls for calls that need not retain the caller’s stack frame

  • Typed function references for more precise function types

Proposal

Feature

Benefit

Relaxed SIMD

Vector operations

Improved performance on math-heavy workloads

Tail-call optimization

Recursive calls

Reduced stack usage and faster function recursion

Typed function references

Function reference types

More precise typing for function references

All of these aim to squeeze more speed and reliability out of your modules. You can track each proposal’s progress on the official WebAssembly proposals page.

Native Garbage Collection Integration

For years, lack of GC support forced languages like Java and C# into workarounds. With the WebAssembly GC proposal, included in Wasm 3.0, the standard now provides GC types that language toolchains can use instead of implementing all managed-memory behavior inside a module. Check your toolchain and target runtime before relying on the feature.

Advancements in Parallelism and Shared Memory

High-performance applications thrive on multiple cores. WASM’s thread proposal—listed at Phase 4 separately from Wasm 3.0—defines shared memory and atomic operations. These give programs tools for parallel work, but do not make application code automatically free of data races. Check support in the runtimes you target.

Image

Expanding the Component Model and Developer Tooling

The emerging component model standardizes how modules talk to each other, regardless of language. That means you can compose a Rust data-parser, a Go business-logic layer, and a C++ crypto engine into one seamless application.

While that’s unfolding, toolchains are getting friendlier too. Recent updates include:

  1. Better DWARF debugging support

  2. Improved source-map generation

  3. Faster incremental builds

Pushing WebAssembly Beyond the Browser

WASI (WebAssembly System Interface) has matured into a lightweight runtime for servers, edge nodes, and even IoT devices. Today, you’ll find WASM-based microservices running on cloud-native platforms and edge routers alike. Major cloud providers now offer WASM runtimes alongside containers.

If you’re evaluating WASM for request-time work at the edge, see our guide to JavaScript edge architecture and its WebAssembly pattern for example tasks, runtime constraints, and a benchmarking next step.

Edge AI and In-Browser Machine Learning

Projects like Candle demonstrate near-native inference speeds right in the browser or at the network edge. This removes the round-trip to a remote server, slashing latency for real-time AI applications.

Integrations with JavaScript Frameworks

In a React app, you can load a WASM module through browser WebAssembly APIs, call its exports, and display the result in your UI. For an example using React hooks, see the WebAssembly and React guide

WebAssembly’s sandbox model remains a strong defense, but its compact binary format also attracted obfuscated malware and cryptojacking scripts. According to the Palo Alto Networks’ Unit42 report, WebAssembly-based cryptojacking attempts fell by 25% in 2023 as detection tools improved. Still, staying on top of security patches is critical.

Memory Limits and Real-World Performance Trade-Offs

On desktop browsers, you can allocate gigabytes of linear memory. Mobile browsers, however, often cap allocations around 300 MB—beyond that, instantiation can fail without warning. And while SIMD and threads promise big wins, some benchmarks show only modest gains over highly optimized JavaScript, thanks to advanced JITs and direct DOM access in JS engines.

A Glimpse at the WASM 3.0 Ecosystem

Here are the standout trends you’ll see over the next year:

  • Broad support for native garbage collection

  • Threads progressing separately from Wasm 3.0’s relaxed SIMD

  • Further refinement of the component model for polyglot apps

  • Continued expansion of WASI into server, edge, and IoT realms

  • Deeper integration with React, Vue, and other frameworks

  • More in-browser AI and edge-compute use cases

Trend

Description

Native GC

Languages manage memory

Multi-threading & SIMD

Parallel performance

Component model

Polyglot composition

WASI expansion

New runtimes

Framework integration

React/Vue APIs

AI & edge compute

Real-time inferencing

Charting the WASM Horizon

WebAssembly 3.0 brings features including GC and tail calls into the live standard, while Threads progresses separately. Before adopting a feature, check support in your intended toolchain and runtimes, then benchmark the workload that matters to your users.

 Korneliusz Caputa

By Korneliusz Caputa

More from our Blog

Keep reading