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:

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

[8]

[9]

[10]

[3]

Runtime Foco Observaciones
Wasmtime Referencia Bytecode Alliance Default más seguro
Wasmer Comercial + OSS Ecosistema amplio
WasmEdge Cloud-native CNCF, foco K8s
Fermyon Spin Serverless Wasm Framework completo

Soporte de lenguajes

La madurez varía significativamente:

  • Rust: con soporte nativo y de primer nivel. 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:

Aspecto Component Wasm Contenedor
Cold start <1 ms 100 ms-1 s
Tamaño KB-MB MB-GB
Aislamiento Muy fuerte Bueno
Ecosistema Emergiendo Masivo
OS access Limitado (más seguro) Completo

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 parte de Cloudflare Workers son señales claras de que el ecosistema se está consolidando.

Preguntas frecuentes

¿Sustituye WebAssembly con WASI 0.2 a los contenedores en producción?

No: los complementa en casos concretos. Un component Wasm arranca en frío en menos de 1 ms frente a los 100 ms-1 s de un contenedor, pesa KB-MB en lugar de MB-GB y ofrece un aislamiento más fuerte con acceso limitado al SO. Eso lo hace ganador en edge functions, plugins y sandboxing de código no confiable. Para apps tradicionales con dependencias de SO, workloads stateful intensivos en disco o red y heavy computation, los contenedores siguen siendo el default correcto.

¿En qué lenguaje conviene empezar a escribir components Wasm?

En Rust, que es hoy el camino con menor fricción: cargo-component genera components con soporte nativo y de primer nivel. C/C++ es maduro vía wasi-sdk; Go funciona con TinyGo pero con limitaciones frente a Go completo; JavaScript pasa por Javy para edge y Componentize-JS; Python es experimental con componentize-py y .NET tiene soporte emergente. Los lenguajes con GC como Java, C# o Python son además menos eficientes compilados a Wasm.

¿Puedo ejecutar components Wasm en Kubernetes sin contenedores?

Sí, es posible hoy. runwasi es un runtime de containerd que ejecuta components Wasm directamente, y kwasm es un operator que habilita Wasm en los nodos del clúster sin cambiar el runtime base. Encaja sobre todo en workloads edge-adjacent. Ten presentes las limitaciones actuales: muchas librerías de terceros aún no tienen bindings para Wasm, el debugging es más difícil que en nativo o contenedor y el soporte async no estará completo hasta WASI 0.3.

Fuentes

  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. https://wasmtime.dev/
  9. https://wasmer.io/
  10. https://wasmedge.org/
  11. runwasi
  12. kwasm
  13. Bytecode Alliance — WASI 0.2 Launched
  14. The WebAssembly Component Model