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í ha costado 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. Al arrancar 2026 con un estándar publicado y varios runtimes con soporte sólido, toca evaluar qué ha cambiado en la práctica y qué casos reales han empezado a moverse.
Qué trae preview 3 que faltaba en preview 2
Preview 2 ya era un estándar perfectamente usable para muchos casos. 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, falta de streams bidireccionales bien definidos, y limitaciones en la interacción entre componentes concurrentes.
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. Los streams bidireccionales permiten implementar de forma portable protocolos como WebSocket, gRPC o cualquier protocolo con comunicación continua entre cliente y servidor. Y la concurrencia entre componentes está especificada con suficiente detalle para construir arquitecturas reales donde varios componentes colaboran mediante mensajes asíncronos.
El cambio práctico más importante es que ya no hay que elegir entre portabilidad y async. Hasta 2025 los casos que necesitaban concurrencia seria acababan o fuera de WASI con runtimes propios, o con soluciones ad-hoc que rompían la compatibilidad entre runtimes. Con preview 3, un componente que usa async se ejecuta en wasmtime, WasmEdge, JCO (para navegador) y en los principales runtimes comerciales sin cambios, siempre que estos hayan actualizado a preview 3, cosa que la mayoría ha hecho durante el primer trimestre de 2026.
Runtimes maduros y casos en producción
Wasmtime, el runtime de referencia mantenido por Bytecode Alliance, alcanzó soporte completo de preview 3 con su versión 26, liberada en noviembre de 2025. WasmEdge hizo lo propio en enero de 2026 con su versión 0.15. Spin de Fermyon incorporó preview 3 en su versión 3.5, publicada a inicios de año. Estas tres bases cubren la mayoría de casos reales que veo hoy en producción.
Un caso concreto que he visto funcionar muy bien es API gateway personalizado 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 del cambio 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, testear aisladamente, 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.
Otro caso práctico es plugins de extensión para aplicaciones SaaS. Varios productos que históricamente permitían extensiones mediante JavaScript sandbox han movido su arquitectura a componentes WebAssembly. La razón práctica es que los plugins Wasm son más rápidos, más seguros (sandbox nativo del runtime) y portables entre lenguajes. Preview 3 ha sido clave aquí porque muchos plugins necesitan hacer llamadas HTTP o acceder a APIs internas del producto con 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 notablemente. WASI Cloud, la familia de interfaces estandarizadas para servicios en la nube (colas, blobs, KV, pub/sub, LLM), ha estabilizado 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. La portabilidad de verdad que Kubernetes prometió pero nunca entregó del todo, empieza a verse a este nivel.
Las herramientas de construcción también han mejorado. Cargo component (para Rust), jco (para JavaScript y TypeScript) y el ecosistema Go con tinygo o el compilador oficial WebAssembly, producen componentes preview 3 con herramientas maduras, errores decentes y documentación que ya no es solo el README del repo. El tooling ha alcanzado un nivel que hace un año era pobre y que ahora permite productividad real.
Las bibliotecas de componentes reutilizables son el paso siguiente. Ya existen componentes estándar para parseo JSON, cliente HTTP, cliente Postgres, serialización Protobuf, cifrado con libsodium y muchos más. 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 en 2026 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())))
}El fragmento anterior 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. El 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 a preview 3, 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, pero hoy sigue siendo fricción real.
Los tiempos de inicio en frío siguen siendo peores que con binarios nativos. Para cargas que requieren latencia muy baja en invocaciones puntuales, Wasm sigue añadiendo unos pocos milisegundos en startup del runtime y en validación del componente. Para cargas de larga duración esto no importa, pero para microservicios invocados miles de veces por minuto con SLO de latencia 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 (profiling, tracing) requiere más esfuerzo. Hay progreso continuo pero el tooling de diagnóstico sigue por detrás del de cualquier lenguaje nativo maduro.
Cuándo compensa adoptar ya
Para un equipo que se esté planteando Wasm en producción en 2026, mi recomendación es distinguir tres escenarios. Primero, 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.
Segundo, casos de sustitución de arquitecturas existentes que funcionan bien. Si tienes contenedores Docker con microservicios sanos, reemplazarlos por componentes Wasm raramente compensa, aunque técnicamente sea posible. El coste de migración y de reentrenar al equipo normalmente supera las ganancias en densidad o en tiempo de arranque. Cambia solo si hay una razón operativa concreta.
Tercero, casos donde la promesa de Wasm (portabilidad extrema, aislamiento fuerte, densidad) resuelve un problema real que tienes. Equipos que necesitan desplegar la misma lógica en servidor, edge y navegador sin reescribir, equipos que quieren ejecutar código de terceros con garantías de aislamiento, equipos que operan a escalas donde densidad por máquina importa mucho. Aquí Wasm con preview 3 es la opción técnica más sólida de 2026 y adoptarla es decisión estratégica acertada.
Cuándo compensa
La lectura honesta de preview 3 a principios de 2026 es que por fin WebAssembly ha alcanzado 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, y no hace falta adoptarlo en todo. Pero para los nichos donde sus ventajas son reales, 2026 es el año en que dejar de esperar y empezar a usarlo, con la expectativa de que el estándar es estable, los runtimes son compatibles y el tooling permite productividad genuina.
