Why WebAssembly Should Stay a Living Standard

WebAssembly should stay a living standard, not freeze into a final Recommendation.

WebAssembly is right to remain a living standard instead of chasing Recommendation status, because the platform’s value comes from shipping incremental, interoperable change faster than the old standards cycle allows.

The evidence is already in the document itself: the WebAssembly Working Group says it will keep the Core Specification in Candidate Recommendation and update it continuously, while the spec also describes version 3.0 and explicitly expects future incremental releases. That combination is not a bug. It is the correct operating model for a runtime layer that has to serve browsers, servers, embedded systems, and language toolchains at once. A frozen spec would force the ecosystem to wait for artificial publication milestones while implementers are already dealing with new semantics, new validation rules, and new instruction families.

First, the technical surface is still moving too fast to freeze

WebAssembly is no longer a tiny sandbox for compiled C and C++. The core spec now spans reference types, recursive types, exception handling, vector operations, relaxed numeric operations, and a dense validation and execution model. That is not the profile of a mature format that can be locked and left alone. It is the profile of a platform still absorbing features that change how code is represented, checked, and executed. If the standard pretends that this is settled, it will create a false sense of completeness where the real work is still happening in the open.

Look at the structure of the document: it devotes major sections to validation, execution, binary format, text format, and a long appendix of change history and implementation limits. That breadth matters. WebAssembly is not just an encoding; it is a contract between compilers, engines, and host environments. A living standard lets the working group patch ambiguity and align semantics with shipping engines as soon as those issues surface. In a system where a single mismatch can break portability or soundness, waiting for a ceremonial Recommendation is the slower and riskier path.

Second, the ecosystem depends on continuous interoperability work

WebAssembly succeeds only if a module compiled by one toolchain runs the same way in another engine. That sounds obvious, but the spec’s own emphasis on implementation reports, issue tracking, and archived comments tells the real story: interoperability is an ongoing negotiation, not a one-time achievement. The living-standard model keeps that negotiation attached to the document instead of burying it in separate errata, blog posts, or vendor-specific behavior. For developers, that means the spec stays closer to reality.

There is also a practical deployment reason. WebAssembly is used in browsers, but the spec explicitly says it can be embedded in standalone VMs and integrated into other environments. That breadth makes a slow standards cadence especially harmful. Browser engines, server runtimes, and edge platforms do not move in lockstep, and they do not all need the same features on the same date. A continuously maintained core spec gives implementers a shared target while they stage support at their own pace. Freezing the standard would not stop divergence; it would only make divergence harder to reconcile.

The counter-argument

The strongest case for Recommendation status is institutional trust. A final standard signals stability, reduces anxiety for conservative buyers, and gives procurement teams a clean line between “done” and “in progress.” It also forces the working group to narrow scope and resolve disagreements before publishing, which can improve discipline. For some technologies, that pressure is healthy. It protects users from a moving target and gives vendors a clear finish line.

That argument is serious, but it does not fit WebAssembly’s reality. The core format is already a foundation for multiple higher-level features and related specifications, and the document itself admits that some parts are work in progress. Freezing the core would not create calm; it would create a mismatch between the published standard and the living implementation surface. The right limit is not “never stabilize.” The right limit is “stabilize behavior where interoperability demands it, and keep the publication model flexible enough to absorb the rest.” WebAssembly needs a stable contract, not a static archive.

What to do with this

If you are an engineer, treat the living standard as a signal to read the current spec, not an excuse to rely on folklore or stale blog posts. Build against the implementation report, watch the issue tracker, and test against multiple engines. If you are a PM or founder, plan for feature rollouts that track spec evolution instead of waiting for a final stamp. The winning strategy is to align product decisions with the current interoperable subset, then expand as the standard and implementations converge. In WebAssembly, speed comes from continuous standardization, not from pretending the platform is finished.