WASI preview 3 se estabilizó oficialmente a finales de 2025, después de más de dos años de trabajo sobre las bases que preview 2 dejó en 2024. Llegar aquí costó más de lo que la comunidad esperaba, y durante un tiempo parecía que el proyecto se había atascado en discusiones sobre async y modelo de componentes. El año 2026 arranca con un estándar publicado y con runtimes que ya lo soportan de forma sólida. Toca evaluar qué ha cambiado en la práctica y qué casos reales han empezado a moverse.

Puntos clave

  • Preview 3 añade lo que faltaba a preview 2: async nativo, streams bidireccionales bien definidos y concurrencia entre componentes con semántica especificada.

  • Ya no hay que elegir entre portabilidad y async: un componente con async se ejecuta en wasmtime, WasmEdge, JCO y los principales runtimes comerciales sin cambios.

  • Los casos de producción que mejor funcionan: API gateways con lógica compleja y plugins de extensión para aplicaciones SaaS.

  • WASI Cloud estabilizó su primera versión oficial: el mismo componente Wasm habla sobre AWS, Azure, Google Cloud o backend auto-alojado cambiando solo el adaptador.

  • Roces que persisten: soporte irregular en runtimes comerciales más allá de wasmtime, WasmEdge y Spin; tiempos de inicio en frío todavía por encima de binarios nativos; depurado más torpe.

Qué trae preview 3 que faltaba en preview 2

Preview 2 ya era un estándar perfectamente usable en el caso general. Aportaba interfaces para filesystem, redes, aleatoriedad, reloj y manejo de entorno, todo sobre el modelo de componentes introducido en 2024. Pero había tres carencias que limitaban adopción en escenarios avanzados:

  • Ausencia de async nativo: los casos que necesitaban concurrencia seria acababan o fuera de WASI con runtimes propios, o con soluciones ad-hoc que rompían la compatibilidad.

  • Falta de streams bidireccionales bien definidos: limitaba la implementación portable de protocolos como WebSocket o gRPC.

  • Limitaciones en la interacción entre componentes concurrentes: no había suficiente especificación para construir arquitecturas donde los componentes colaboran entre sí mediante mensajes asíncronos.

Preview 3 resuelve estas tres carencias de forma coordinada. El modelo async es ahora parte del propio estándar, con primitivas para futures, streams y cancelación que encajan naturalmente en el modelo de componentes. Con preview 3, un componente que usa async se ejecuta en wasmtime, WasmEdge, JCO (para navegador) y en los principales runtimes comerciales sin cambios.

Runtimes maduros y casos en producción

Wasmtime[1] (Bytecode Alliance) alcanzó soporte completo de preview 3 con su versión 26 en noviembre de 2025. WasmEdge[2] lo hizo en enero de 2026 con su versión 0.15. Spin de Fermyon[3] incorporó preview 3 en su versión 3.5 a inicios de año. Estas tres bases cubren el grueso de los casos reales que veo hoy en producción.

Caso práctico 1: API gateway con Spin 3.5. Una empresa que necesitaba lógica compleja de enrutado, transformación de peticiones y políticas de autorización específicas ha reemplazado su anterior gateway NGINX con scripts Lua por un conjunto de componentes Wasm en Spin. La razón principal no fue rendimiento, el NGINX era suficiente, sino mantenibilidad.

Los componentes Wasm se pueden escribir en Rust, TypeScript o Go con el modelo que prefieras, probar de forma aislada, versionar de forma independiente y desplegar sin reiniciar el proceso principal. Preview 3 fue necesario porque las políticas más complejas requerían llamadas asíncronas a servicios externos durante la evaluación de autorización.

Caso práctico 2: plugins de extensión para aplicaciones SaaS. Hay productos que históricamente permitían extensiones mediante JavaScript sandbox y han movido su arquitectura a componentes WebAssembly. Las razones: los plugins Wasm son más rápidos, más seguros (sandbox nativo del runtime) y portables entre lenguajes. Preview 3 fue clave aquí porque los plugins que hacen llamadas HTTP o acceden a APIs internas necesitan patrones async, y preview 2 obligaba a trucos torpes o a funciones bloqueantes que degradaban rendimiento.

El ecosistema de componentes y bibliotecas

Más allá del estándar, el ecosistema de componentes precompilados se ha enriquecido. WASI Cloud (la familia de interfaces estandarizadas para servicios en la nube: colas, blobs, KV, pub/sub, LLM) estabilizó su primera versión oficial con preview 3 integrado. Esto permite construir aplicaciones portables entre proveedores: el mismo componente Wasm que habla WASI Cloud funciona sobre AWS, Azure, Google Cloud o un backend auto-alojado, con solo cambiar el adaptador.

Las herramientas de construcción también han mejorado:

  • Cargo component para Rust.

  • jco para JavaScript y TypeScript.

  • El ecosistema Go con tinygo o el compilador oficial WebAssembly.

Todos producen componentes preview 3 con herramientas maduras, errores decentes y documentación que ya no es solo el README del repo.

Las bibliotecas de componentes reutilizables son el paso siguiente. Ya existen componentes estándar para parseo JSON, cliente HTTP, cliente Postgres, serialización Protobuf o cifrado con libsodium, y la lista sigue creciendo. Componerlos dentro de una aplicación es tan sencillo como declarar dependencias en el manifest y dejar que el linker resuelva la composición. Este modelo permite reutilizar lógica entre lenguajes de forma natural: un componente compilado desde Rust lo consume sin fricción un componente escrito en TypeScript, sin FFI.

Un ejemplo mínimo con Spin y async

Un patrón común es una pequeña API web que consume servicios externos con concurrencia. El siguiente fragmento muestra cómo queda en Spin 3.5 con Rust y WASI preview 3:

use spin_sdk::http::{Method, Request, Response, Router};
use spin_sdk::http_component;
use futures::future::join_all;

#[http_component]
async fn handle_request(req: Request) -> anyhow::Result<Response> {
    let urls = vec![
        "https://api.one.example/status",
        "https://api.two.example/status",
        "https://api.three.example/status",
    ];

    let fetches = urls.iter().map(|u|
        spin_sdk::http::send::<_, Response>(Request::new(Method::Get, u)));

    let results = join_all(fetches).await;
    let healthy = results.iter().filter(|r| r.is_ok()).count();

    Ok(Response::new(200, format!("{} de {} saludables", healthy, urls.len())))
}

Este fragmento habría sido imposible en preview 2 sin trucos fuera de la especificación. En preview 3 es sintaxis natural, con concurrencia real entre peticiones HTTP, y se ejecuta en cualquier runtime compatible sin código específico. Esta ergonomía es lo que ha desbloqueado casos que llevaban dos años esperando.

Dónde sigue habiendo roces

No todo es color de rosa:

  • Soporte preview 3 en runtimes comerciales más allá de los mencionados sigue siendo irregular. Algunos proveedores de edge computing que adoptaron temprano preview 2 están tardando más de lo esperado en migrar, lo que obliga a compilar para la versión más vieja si se quiere portabilidad máxima. La mayoría estabilizará durante el primer semestre de 2026.

  • Tiempos de inicio en frío siguen siendo peores que con binarios nativos. Para cargas que requieren latencia baja en invocaciones puntuales, Wasm sigue añadiendo unos pocos milisegundos en startup. Para cargas de larga duración esto no importa, pero para microservicios invocados miles de veces por minuto con SLO agresivos, hay que medir.

  • El depurado sigue siendo más torpe que el de binarios nativos. Las trazas de pila en componentes Wasm son menos legibles, los depuradores visuales son más limitados y la instrumentación de bajo nivel requiere más esfuerzo.

Cuándo compensa adoptar

Para un equipo que se esté planteando Wasm en producción, conviene distinguir tres escenarios:

Casos donde Wasm aporta valor claro y no urgente: plugins para productos SaaS, funciones en edge computing, lógica embebida en aplicaciones mayores. Aquí vale la pena arrancar ya con preview 3, sabiendo que la curva inicial es notable pero el retorno a medio plazo es sólido.

Casos de sustitución de arquitecturas existentes que funcionan bien: si tienes contenedores Docker con microservicios sanos, reemplazarlos por componentes Wasm raramente compensa. Migrar y reentrenar al equipo cuesta más de lo que se gana en densidad o en tiempo de arranque. Cambia solo si hay una razón operativa concreta.

Casos donde la promesa de Wasm resuelve un problema real: portabilidad entre servidor, edge y navegador sin reescribir; ejecución de código de terceros con garantías de aislamiento; escalas donde densidad por máquina importa mucho. Aquí Wasm con preview 3 es la opción técnica más sólida y adoptarla es decisión estratégica acertada.

Para el detalle técnico de qué introdujo preview 3, lee hilos y async en WebAssembly.

Conclusión

La lectura honesta de preview 3 es que WebAssembly ha alcanzado por fin la madurez que prometía desde 2019. Preview 2 ya permitía casos interesantes, pero preview 3 cierra el círculo con async, streams y composición concurrente. El ecosistema está empezando a florecer de verdad, con runtimes maduros, bibliotecas reutilizables y casos de producción demostrables.

No es sustituto universal de contenedores ni de funciones serverless propietarias. Pero para los nichos donde sus ventajas son reales (portabilidad extrema, aislamiento fuerte, densidad) es buen momento para dejar de esperar y empezar a usarlo. El estándar es estable, los runtimes son compatibles y el tooling permite productividad genuina.

La adopción de Wasm también tiene implicaciones para la arquitectura de agentes. Cuando un sistema distribuido como el que describe WASI preview 3 para edge necesita componentes portables entre múltiples runtimes, hace falta un canal común. Los protocolos de comunicación como A2A son ese canal estándar para que esos componentes coordinen trabajo.

Preguntas frecuentes

¿Qué runtimes soportan ya WASI preview 3?

Los tres runtimes que cubren el grueso de la producción son Wasmtime, WasmEdge y Spin. Wasmtime (Bytecode Alliance) alcanzó soporte completo con la versión 26 en noviembre de 2025, y WasmEdge con la 0.15 en enero de 2026. Spin de Fermyon lo incorporó en la 3.5, y para navegador está JCO. El soporte en runtimes comerciales sigue siendo irregular: algunos proveedores de edge computing que adoptaron pronto preview 2 están tardando en migrar, y la mayoría estabilizará durante el primer semestre de 2026.

¿Debería migrar mis microservicios en Docker a componentes Wasm?

Si los contenedores funcionan bien, rara vez compensa: el coste de migración y de reentrenar al equipo suele superar las ganancias en densidad o tiempo de arranque. Cambia solo con una razón operativa concreta, y Wasm con preview 3 sí es la opción más sólida cuando resuelve un problema real. Los casos son la misma lógica en servidor, edge y navegador sin reescribir, la ejecución de código de terceros con garantías de aislamiento, o las escalas donde la densidad por máquina importa. Plugins para SaaS y funciones en edge son los casos de valor claro.

¿Puedo hacer peticiones HTTP concurrentes desde un componente Wasm?

Con preview 3 sí, porque el async forma parte del propio estándar. Un componente puede lanzar en paralelo tantas peticiones a servicios externos como necesite y esperar a todas, como en una pequeña API en Spin 3.5 escrita en Rust. Ese mismo componente se ejecuta sin cambios en wasmtime, WasmEdge o JCO, mientras que en preview 2 eso exigía trucos fuera de la especificación o funciones bloqueantes que degradaban el rendimiento. Ten en cuenta que los arranques en frío siguen añadiendo unos pocos milisegundos frente a un binario nativo.

Fuentes

  1. Wasmtime
  2. WasmEdge
  3. Spin de Fermyon
  4. WASI en GitHub