Following the Wasm Proposal Process

This page answers one question: you read about a promising WebAssembly feature — a new proposal for strings, threads, memory, stack switching — and need to know whether you can use it in production, experiment with it, or should wait. You want to understand the process that standardises features and how to read a proposal’s phase and implementation status.

Prerequisites

  • [ ] Interest in a specific post-MVP feature.
  • [ ] Access to the WebAssembly proposals repository and browser status pages.
  • [ ] A view of the browsers and runtimes your users run.

Who decides

WebAssembly is standardised at the W3C. The Community Group (CG), open to anyone, does most design work: proposals are discussed in meetings and in GitHub repositories, one per proposal, each with champions who drive it. The Working Group (WG), made up of W3C members, publishes the formal specification once features are mature. Implementers — browser engine teams (V8, SpiderMonkey, JavaScriptCore) and standalone runtimes (Wasmtime and others) — participate closely, because a feature only becomes standard once it is implemented and shown to work. WASI and the Component Model are developed in a related subgroup with their own phase process.

The phases

Proposals move through numbered phases, with votes in the Community Group (and later the Working Group) to advance:

  • Phase 0 — pre-proposal. An idea presented to the CG; no commitment.
  • Phase 1 — feature proposal. The CG agrees the problem is worth solving; a repository and champions exist; design is exploratory.
  • Phase 2 — feature description available. A precise description (often spec text and a prototype) exists; design is stabilising but may change.
  • Phase 3 — implementation phase. Spec text and tests are complete enough for engines to implement, often behind flags; changes are still possible based on implementation experience.
  • Phase 4 — standardise the feature. At least two web engines have shipped or are ready to ship; the feature is considered stable and handed to the WG.
  • Phase 5 — the feature is standardised. Merged into the official specification.
A proposal's journey through the phases An idea starts at phase 0, gains a repository and champions at phase 1, a precise description at phase 2, spec text and implementations behind flags at phase 3, shipping in at least two web engines at phase 4, and merges into the specification at phase 5. Shipping by default in browsers usually happens around phase 4. 0 phase idea presented 1 phase repo + champions 2 phase precise description 3 phase spec text, flags 4 phase shipped in 2+ engines 5 phase in the spec

Step 1 — find the proposal and its phase

The WebAssembly/proposals repository lists active proposals by phase, with links to each proposal’s repository, overview document and champions. Read the overview (usually proposals/<name>/Overview.md in the proposal repo) for motivation and design, and the issues for open questions. The phase tells you how likely the design is to change: phase 1–2 designs often change substantially; phase 3 designs change rarely and mostly in details; phase 4 is stable.

Step 2 — check implementation status

Phase and implementation are related but separate. A phase 3 feature may be implemented in one engine behind a flag, in another by default, and absent in a third. Check the feature status table on webassembly.org (the “feature extensions” page), browser compatibility data (for example MDN and caniuse for WebAssembly features), and each runtime’s documentation (Wasmtime, Node versions). For browsers, “shipped” means enabled by default in a stable release — features in origin trials or behind flags are not available to ordinary users.

What each phase means for using a feature Phases 0 to 2 are for following and giving feedback, since designs change. Phase 3 suits experiments behind flags or origin trials, with production use only where an engine has shipped it and a fallback exists. Phases 4 and 5 are stable, with production use limited by which engines your users run. phase design stability sensible use 0–2 likely to change follow, give feedback 3 mostly stable experiments; production only with fallback 4 stable production where your engines ship it 5 standardised production; check engine coverage

Step 3 — decide whether to ship

A practical rule: use a feature in production when it is shipped by default in the engines most of your users run, and either all your users have it or you have a fallback build for the rest. For server-side runtimes you control, the bar is lower — you can enable a phase 3 feature in a pinned runtime version if its semantics are unlikely to change, accepting a possible migration. For experiments and demos, flags and origin trials are fine. Record which features each build uses, so you can revisit decisions as support changes.

Step 4 — give feedback

The proposal process depends on real-world feedback. If you prototype with a phase 2–3 feature and find a problem — performance cliffs, awkward toolchain integration, missing operations — file an issue in the proposal’s repository with a concrete example. Champions actively seek such reports, and phase 3 is the last good time for them to influence the design.

Step 5 — follow toolchain support

A feature is usable only when your toolchain emits it: LLVM, Binaryen, Emscripten, wasm-bindgen, language compilers. Toolchains often support a feature behind a flag before engines ship it by default, and enable it by default only after broad engine support. Watch toolchain release notes alongside engine status; a toolchain enabling a feature by default is a signal that it is considered widely deployable — and a reminder to check your oldest supported engines.

A note on WASI and the Component Model

WASI and Component Model work follows a similar phase process in the WASI subgroup, with versioned releases (such as WASI 0.2) bundling interfaces that reached sufficient maturity. Runtimes implement those releases rather than individual proposals. Check which WASI release your runtime implements before relying on an interface.

Reading a proposal’s overview efficiently

Proposal repositories are long, and much of the content is for implementers. For a product decision, read in this order: the motivation section (does it solve your problem?), the overview of new types and instructions (what would your toolchain emit?), the JavaScript API changes if any (does your loader need updating?), and the open questions or issues labelled for the current phase (what might still change?). Then check the tests directory: a proposal with a comprehensive test suite in the spec’s test format is close to implementable. Skim recent meeting notes for the proposal’s name to see whether anything contentious is under discussion. Twenty minutes of focused reading usually answers “should we plan around this?” better than secondary summaries, which are often out of date by the time you read them.

Keeping a feature watch list

Teams that depend on Wasm benefit from a short watch list: the proposals that would matter to your product (stack switching for async-heavy code, memory64 for large datasets, relaxed SIMD for ML kernels, shared-everything threads, new string or GC features for your language), each with its current phase, browser status, toolchain status and the decision it would unlock. Review it each quarter. When a feature crosses the threshold you set — shipped by default in your main engines, supported by your toolchain — the watch list turns into a plan: build a variant, measure, and decide whether to adopt. Without such a list, useful features tend to be noticed only years after they become available.

Runtimes move differently

Standalone runtimes such as Wasmtime often implement proposals earlier than browsers, behind configuration flags, because embedders control their environment. That makes them good places to experiment, but behaviour can still change until the proposal reaches phase 4.

Expected output

You can locate a proposal’s repository, read its phase and design overview, check its implementation status per browser and runtime, decide whether it is production-ready for your user base (shipped by default where needed, with a fallback otherwise), and know where to send feedback while the design can still change.

Gotchas

  • Equating phase 4 with “every browser”. It means two web engines; check yours.
  • Using flagged features in production. Users do not have flags. Wait for default shipping.
  • Building on phase 1–2 designs. They change. Prototype only.
  • Ignoring toolchain support. Engines may support what your compiler cannot yet emit.
  • Forgetting fallback builds. Partial support needs a plan for the rest.
  • Relying on outdated summaries. Phases and support change. Check the repositories and status pages directly.

Performance note

Features that reach phase 4 often bring large practical wins — SIMD, threads, exception handling and GC each changed what could run well on the web — which is why tracking the process pays off for performance planning.

Typical speed-ups from features after standardisation Illustrative speed-up factors reported for suitable workloads after adopting SIMD for numeric kernels, threads for parallel work on four cores, and native exception handling for C++ code with many try blocks. speed-up for suitable workloads (×) SIMD (numeric kernels) 2.5 × threads (4 cores) 3.2 × native exceptions (C++) 2 ×

Frequently Asked Questions

Can anyone join the Community Group? Yes — it is open; participation requires agreeing to W3C community terms.

How long does a proposal take? Years is common for large features; small ones move faster.

What is an origin trial? A browser mechanism to enable an experimental feature for registered sites temporarily, for feedback.

Where are meetings documented? Meeting notes are published in the WebAssembly meetings repository.

What should I read first in a proposal repository? Motivation, the overview of new types and instructions, any JavaScript API changes, and open questions for the current phase.

Should my team keep a list of proposals to watch? Yes — track phase, browser and toolchain status for the few that matter, and review quarterly.

Are runtimes a good place to try new proposals? Yes — runtimes like Wasmtime often implement them earlier behind flags, though behaviour can change before phase 4.

← Back to Post-MVP Wasm Proposals in Practice