WASI 0.2: The New Standard Interface for WebAssembly

Actualizado: 2026-05-03

WebAssembly^[1] has gone from being “JavaScript but faster in the browser” to a serious platform for running portable code outside the browser. The key piece of that transition is WASI (WebAssembly System Interface), the standard defining how WASM modules access system resources (filesystem, network, time). By late 2023 the finalisation of WASI Preview 2 approaches, a substantial rewrite from Preview 1. We cover what changes, why, and what impact it will have.

Key takeaways

• WASI Preview 1 had a POSIX-like model that didn’t fit edge computing or inter-module composition well.
• Preview 2 introduces the Component Model with typed WIT interfaces — two modules compiled from different languages can communicate without manual serialisation.
• Granular capabilities allow running untrusted code with minimum permissions, the foundation for secure plugins and edge functions.
• Wasmtime, wasmer, WasmEdge, and Spin already have support or are adding it.
• Even if you don’t write WASM directly, you already use it: Cloudflare edge functions and Envoy plugins run WASM.

The Problem With Preview 1

WASI Preview 1 (published 2019) made WebAssembly outside the browser possible. But as the ecosystem matured, its limitations became evident:

• POSIX-like model. Designed thinking about filesystem and Unix-style syscalls. Doesn’t fit modern cases like cloud functions, edge computing, or IoT.
• No composability. Two WASM modules couldn’t easily compose — communicate in rich types, not just bytes.
• No rich types at the interface level. Just integers, floats, pointers, and memory. Strings, structs, and lists required manual serialisation.
• Limited capabilities. You granted access to the entire filesystem, not granular resources.

Preview 2 rewrites the base to solve these problems, while keeping backward compatibility with Preview 1 during the transition.

The Component Model and WIT

The central novelty is the Component Model: WASM modules as components with explicitly typed interfaces, capable of composing with each other at runtime.

Interfaces are described in WIT (WebAssembly Interface Type):

package jacar:examples;

interface logger {
    log: func(message: string);
    levels: enum { debug, info, warning, error }
}

world my-app {
    import logger;
    export run: func();
}

This declares a component that imports a logger interface and exports a run function. WIT supports types like string, record (struct), variant (sum type), list, option, and result — much more expressive than integers and raw memory.

The practical consequence: two WASM components compiled from different languages (Rust + Go + JavaScript) can communicate passing rich structs without manual serialisation. It’s the foundation for an ecosystem of reusable components. This complements the composition patterns being explored in the evolution of the WebAssembly component model.

Granular Capabilities

Preview 2 introduces a much finer capabilities model. Instead of “the module can access the filesystem”, you grant access to specific resources:

• A specific directory, read-only.
• A TCP socket to a specific host, not the whole network.
• A specific environment variable, without free getenv().
• A system timer, without access to wall clocks.

This fits much better with edge functions and plugins in host applications, where you want to run untrusted code with minimum permissions.

Implementation Status

By late 2023, WASI Preview 2 is in release candidate phase. The four main runtimes already have support or are adding it:

• Wasmtime (Bytecode Alliance) — reference implementation, tracking the standard.
• wasmer — progressive support.
• WasmEdge — focus on edge and cloud-native.
• Spin (Fermyon) — framework for WASM apps with early Component Model support.

Language toolchains adding support:

• Rust via cargo-component.
• JavaScript via jco.
• Python via componentize-py.
• Go via tinygo (partial) and experimental projects.

Use Cases That Get Unlocked

Preview 2 + Component Model enable cases where traditional WASM creaked:

• Secure plugins in host applications. Editors, HTTP servers (Apache/Nginx modules in WASM), extensible databases. Granular capabilities avoid malicious-plugin risk.
• Truly multilingual serverless / edge functions. A function in Python can call another in Rust without serialising to JSON.
• Microservices in WASM. Small composable components running on lightweight runtimes, with faster startup than containers.
• Portable smart contracts. Some blockchains (Substrate, NEAR) already use WASM; the component model eases composition.
• Embedded ML. Small models packaged as a WASM component, executable on any runtime supporting the standard.

Remaining Limitations

Areas with work pending by late 2023:

• Threading and concurrency — proposals exist but aren’t yet standardised.
• Garbage collection (important for Java, C#, Python) is in a separate proposal (WASM-GC), not yet integrated.
• Performance in some JIT-compiled languages may not match native runtime.
• Debug tooling is still maturing — debuggers and profilers aren’t as rich as for native code.
• Adoption in massive cases (hyperscale serverless) still incipient.

Why You Care Even If You Don’t Write WASM

As an engineer not directly touching WebAssembly, the WASM/WASI ecosystem is relevant because:

• Edge functions at Cloudflare, Fastly, and others run WASM internally.
• Plugins for tools like Envoy proxy, OPA, and Istio are WASM.
• Databases like SQLite and future Postgres versions explore WASM extensions.
• Smart contracts and blockchains with WASM support grow.

Knowing the standard’s direction helps you understand why certain products make architectural decisions and anticipate capabilities that will arrive.

Conclusion

WASI Preview 2 is WebAssembly’s step toward “serious platform” outside the browser. The Component Model with typed interfaces and granular capabilities solves real limitations that have slowed adoption. Full standardisation arrives in 2024, but the time to start exploring is now — especially if you build tools that would benefit from plugins, edge computing, or secure execution of untrusted code.

1. WebAssembly