WASI 0.2 GA: WebAssembly componible de verdad

Actualizado: 2026-05-03

WASI 0.2 Preview 2 alcanzó GA en enero de 2024 y con ello el Component Model de WebAssembly llegó a producción. Este es un hito decisivo: WebAssembly fuera del navegador deja de ser un experimento para convertirse en una plataforma capaz de ejecutar código polyglot componible. Este artículo cubre qué cambia en la práctica, cuándo tiene sentido elegir Wasm server-side y qué casos son viables hoy.

Puntos clave

• El Component Model resuelve la portabilidad cross-language que frenaba la adopción de Wasm fuera del navegador.
• Para edge functions con cold start crítico, plugins seguros y sandboxing de código no confiable, Wasm ya es viable hoy.
• Para apps tradicionales, Wasm no reemplaza contenedores: los complementa.
• Rust es el lenguaje con menor fricción para components Wasm; el resto están cerrando la brecha.
• El cold start <1 ms frente a los 100-1000 ms de un contenedor es la ventaja diferencial en edge.

Qué es el Component Model

Antes de WASI 0.2, WebAssembly server-side era Preview 1: syscalls tipo Unix y módulos aislados. Cada integración era manual y el código de un módulo no podía composarse con el de otro sin glue code ad hoc.

Preview 2 Component Model añade:

• WIT (WebAssembly Interface Types): definición de interfaces cross-language con tipos estáticos.
• Components: unidad de composición reutilizable, como crates de Rust o npm packages pero multilenguaje.
• Dependency injection: los componentes consumen interfaces, pluggable en tiempo de carga.
• Type safety a través de fronteras de lenguaje.

El resultado: puedes escribir un component en Rust, otro en Go, otro en JavaScript y componerlos sin glue code manual. Cada uno compila a .wasm; el host los ensambla.

Ejemplo de interfaz WIT

package example:greeter@1.0.0;

interface greeter {
    greet: func(name: string) -> string;
}

world host {
    export greeter;
}

Cualquier lenguaje que compile a Wasm component puede implementar o consumir esta interfaz. La toolchain valida los tipos en compile time; los errores de integración se detectan antes del despliegue.

Casos reales viables hoy

Edge serverless

Fastly Compute^[1], Cloudflare Workers^[2] con Wasm y Fermyon Spin^[3] usan Wasm server-side para:

• Cold start inferior a 1 ms frente a los 100-1000 ms de un contenedor frío.
• Sandboxing estricto sin privilegios de OS.
• Portabilidad entre runtimes sin recompilar.
• Escalado masivo sin estado persistente.

Plugins seguros para aplicaciones host

Una aplicación host puede cargar components Wasm como plugins sin acceso privilegiado:

• Envoy Wasm filters^[4]: filtros HTTP portables entre versiones.
• Proxy-Wasm^[5]: spec de plugins para proxies.
• Istio WebAssembly plugins^[6]: extensibilidad del mesh.

Los plugins son portables entre runtimes sin recompilar y sin acceso al sistema del host.

IoT y embedded

Wasm corre en dispositivos con kilobytes de memoria:

• wasm-micro-runtime^[7] (WAMR): para IoT con recursos muy limitados.
• Firmware personalizable sin reflashear el dispositivo.
• Sandbox para código de terceros en dispositivos industriales.

Runtimes principales

Soporte de lenguajes

La madurez varía significativamente:

• Rust: ciudadano de primera clase. cargo-component genera components con mínima fricción.
• C/C++: via wasi-sdk, maduro.
• Go: TinyGo soporta Wasm con algunas limitaciones vs Go completo.
• JavaScript: via Javy (para edge) y Componentize-JS.
• Python: experimental via componentize-py.
• .NET: soporte emergente.

Rust es el camino con menor fricción hoy. Para greenfield, empieza ahí.

Wasm frente a contenedores

No es un reemplazo, es un complemento para casos específicos:

Para edge functions, plugins y sandboxing, Wasm gana en cold start e isolation. Para apps tradicionales con dependencias de OS, contenedores siguen siendo el default correcto.

Kubernetes y Wasm

La integración con K8s madura a través de:

• runwasi^[11]: containerd runtime para ejecutar components Wasm directamente.
• kwasm^[12]: operator para habilitar Wasm en nodos K8s sin cambiar el runtime base.

Ejecutar Wasm en K8s sin contenedores es posible hoy, especialmente para workloads edge-adjacent como Fastly Compute.

Limitaciones actuales

• Ecosistema aún emergiendo: muchas librerías de terceros no tienen bindings para Wasm.
• Debugging: más difícil que en native o contenedor.
• Async: mejora con WASI 0.3 en el roadmap, pero no está completo.
• GC languages: Java, C#, Python son menos eficientes cuando compilan a Wasm.

Cuándo usar Wasm hoy y cuándo esperar

Usar hoy:

• Edge functions donde el cold start es crítico para la UX.
• Plugins seguros para plataformas donde el código es de terceros.
• Sandboxing de código no confiable (IA, scripting de usuario).
• Portabilidad cross-platform (mismo binario en Mac, Linux, Windows, ARM, x86).

Esperar:

• Apps web tradicionales sin ventaja clara sobre contenedores.
• Workloads stateful intensivos en disco o red.
• Heavy computation donde native o GPU siguen siendo mejores.

Conclusión

WASI 0.2 GA es el punto de inflexión en que WebAssembly server-side deja de ser promesa. El Component Model resuelve la portabilidad cross-language que frenaba la adopción. Para equipos construyendo edge functions, plataformas con plugins o sistemas que sandboxean código de terceros, Wasm ya es una elección técnicamente sólida. Para el resto, es una tecnología a seguir de cerca. La convergencia con Kubernetes a través de runwasi y la adopción por part de Cloudflare Workers son señales claras de que el ecosistema se está consolidando.

1. Fastly Compute
2. Cloudflare Workers
3. Fermyon Spin
4. Envoy Wasm filters
5. Proxy-Wasm
6. Istio WebAssembly plugins
7. wasm-micro-runtime
8. Wasmtime
9. Wasmer
10. WasmEdge
11. runwasi
12. kwasm