WASI 0.2: la nueva interfaz estandar para WebAssembly

Actualizado: 2026-05-03

WebAssembly^[1] ha pasado de ser “JavaScript pero más rápido en el navegador” a una plataforma seria para ejecutar código portátil fuera del browser. La pieza clave de esa transición es WASI (WebAssembly System Interface), el estándar que define cómo los módulos WASM acceden a recursos del sistema (filesystem, red, hora). A finales de 2023 se aproxima la finalización de WASI Preview 2, una reescritura sustancial respecto a Preview 1. Cubrimos qué cambia, por qué y qué impacto tendrá.

Puntos clave

• WASI Preview 1 tenía un modelo POSIX-like que no encajaba bien con edge computing ni con composición entre módulos.
• Preview 2 introduce el Component Model con interfaces WIT tipadas — dos módulos compilados desde lenguajes distintos pueden hablar entre sí sin serialización manual.
• Las capabilities granulares permiten ejecutar código no confiable con permisos mínimos, base para plugins y edge functions seguros.
• Wasmtime, wasmer, WasmEdge y Spin ya tienen soporte o lo están añadiendo.
• Si no escribes WASM directamente, ya lo usas: las edge functions de Cloudflare y los plugins de Envoy corren WASM.

El problema con Preview 1

WASI Preview 1 (publicado en 2019) hizo posible WebAssembly fuera del navegador. Pero a medida que el ecosistema maduró, sus limitaciones se hicieron evidentes:

• Modelo POSIX-like. Diseñado pensando en filesystem y syscalls al estilo Unix. No encaja bien con casos modernos como cloud functions, edge computing o IoT.
• No componibilidad. Dos módulos WASM no podían componerse fácilmente entre sí — comunicarse en tipos ricos, no solo bytes.
• Sin tipos ricos a nivel de interfaz. Solo enteros, floats, punteros y memoria. Strings, structs y listas requerían serialización manual.
• Capabilities limitadas. Concedías acceso al filesystem entero, no a recursos granulares.

Preview 2 reescribe la base para resolver estos problemas, manteniendo retrocompatibilidad con Preview 1 durante la transición.

El Component Model y WIT

La novedad central es el Component Model: módulos WASM como componentes con interfaces tipadas explícitamente, capaces de componerse entre sí en runtime.

Las interfaces se describen en 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();
}

Esto declara un componente que importa una interfaz logger y exporta una función run. WIT soporta tipos como string, record (struct), variant (sum type), list, option y result — mucho más expresivo que enteros y memoria cruda.

La consecuencia práctica: dos componentes WASM compilados desde lenguajes distintos (Rust + Go + JavaScript) pueden comunicarse pasando structs ricos sin serialización manual. Es la base para un ecosistema de componentes reutilizables. Complementa los patrones de composición que se están explorando en la evolución del modelo de componentes de WebAssembly.

Capabilities granulares

Preview 2 introduce un modelo de capabilities mucho más fino. En vez de “el módulo puede acceder al filesystem”, concedes acceso a recursos específicos:

• Un directorio concreto, solo de lectura.
• Un socket TCP a un host específico, no a toda la red.
• Una variable de entorno concreta, sin getenv() libre.
• Un timer del sistema, sin acceso a clocks de wall time.

Esto encaja mucho mejor con edge functions y plugins en aplicaciones host, donde quieres ejecutar código no confiable con permisos mínimos.

Estado de implementación

A finales de 2023, WASI Preview 2 está en fase de release candidate. Los cuatro runtimes principales ya tienen soporte o lo están añadiendo:

• Wasmtime (Bytecode Alliance) — implementación de referencia, tracking del estándar.
• wasmer — soporte progresivo.
• WasmEdge — foco en edge y cloud-native.
• Spin (Fermyon) — framework para apps WASM con soporte temprano del Component Model.

Toolchains de lenguaje añadiendo soporte:

• Rust vía cargo-component.
• JavaScript vía jco.
• Python vía componentize-py.
• Go vía tinygo (parcial) y proyectos experimentales.

Casos de uso que se desbloquean

Preview 2 + Component Model habilitan casos donde WASM tradicional rechinaba:

• Plugins seguros en aplicaciones host. Editores, servidores HTTP (módulos Apache/Nginx en WASM), bases de datos extensibles. Las capabilities granulares evitan el riesgo de plugins maliciosos.
• Serverless y edge functions verdaderamente multilingüe. Una function en Python puede llamar a otra en Rust sin serializar a JSON.
• Microservicios en WASM. Componentes pequeños y componibles que se ejecutan en runtimes ligeros, con arranque más rápido que contenedores.
• Smart contracts portables. Algunos blockchains (Substrate, NEAR) ya usan WASM; el Component Model facilita la composición.
• Embedded ML. Modelos pequeños empaquetados como componente WASM, ejecutables en cualquier runtime que soporte el estándar.

Limitaciones que quedan

Áreas con trabajo pendiente a finales de 2023:

• Threading y concurrencia — hay propuestas pero aún no están estandarizadas.
• Garbage collection (importante para Java, C#, Python) está en propuesta separada (WASM-GC), aún no integrada.
• Performance en algunos lenguajes JIT-compiled puede no igualar al runtime nativo.
• Tooling de debug sigue madurando — debuggers y profilers no son tan ricos como para código nativo.
• Adopción en casos masivos (hyperscale serverless) aún incipiente.

Por qué te interesa aunque no escribas WASM

Como ingeniero que no toca WebAssembly directamente, el ecosistema WASM/WASI es relevante porque:

• Edge functions de Cloudflare, Fastly y otros corren WASM internamente.
• Plugins de herramientas como Envoy proxy, OPA e Istio son WASM.
• Bases de datos como SQLite y futuras versiones de Postgres exploran extensiones en WASM.
• Smart contracts y blockchains con soporte WASM crecen.

Conocer la dirección del estándar ayuda a entender por qué ciertos productos toman decisiones de arquitectura y a anticipar capacidades que llegarán.

Conclusión

WASI Preview 2 es el paso de WebAssembly hacia “plataforma seria” fuera del navegador. El Component Model con interfaces tipadas y capabilities granulares resuelve limitaciones reales que han frenado la adopción. La estandarización completa llegará en 2024, pero el momento de empezar a explorar es ahora — sobre todo si construyes herramientas que se beneficiarían de plugins, edge computing o ejecución segura de código no confiable.

1. WebAssembly