WebAssembly 3.0 se convirtió en estándar W3C en septiembre de 2025, estandarizando nueve funcionalidades que llevaban años en fase de propuesta: WasmGC, manejo de excepciones, tail calls, memoria de 64 bits, SIMD de 128 bits y otras. En 2026, por primera vez, WebAssembly está en un punto donde la pregunta ya no es «¿está listo?» sino «¿para qué lo uso?»
WasmGC: el cambio que desbloqueó los lenguajes con GC
El problema histórico de WebAssembly para lenguajes como Java, Kotlin, Dart o C# era el tamaño: para ejecutarse en Wasm, cada módulo tenía que incluir su propio recolector de basura. Una app Dart que de otra forma pesa 2 MB podía llegar a 10 MB en Wasm.
WasmGC resuelve esto: los módulos delegan la gestión de memoria al motor del navegador o del runtime host. El navegador ya tiene un GC; WasmGC permite que los módulos Wasm usen ese mismo GC. El resultado es tamaños de módulo mucho menores y mejor integración con el host.
El ejemplo más visible: Google Sheets migró su motor de cálculo a WasmGC y consiguió velocidad de recálculo 2 veces mayor. Hojas con millones de celdas que tardaban varios segundos ahora terminan en menos de uno.
WASI 0.3 y el Component Model
Fuera del navegador, WebAssembly está cambiando la arquitectura de servicios en la nube. WASI 0.3 trae I/O asíncrono nativo al Component Model: los módulos Wasm ahora pueden declarar operaciones asíncronas con tipos future y stream que el runtime host gestiona sin bloquear el hilo.
El Component Model es quizá el cambio más profundo a largo plazo: permite componer módulos escritos en lenguajes diferentes como si fueran librerías normales, sin FFI ni llamadas de red. Una librería en Rust puede exportar funciones que consume un programa en Python, que a su vez llama a código en C, todo dentro del mismo proceso Wasm, con tipos verificados entre componentes a través de WIT (WebAssembly Interface Types).
Casos de uso reales en 2026
Navegador. Google (Maps, Earth, Meet, Photos) y Adobe (Photoshop Web) son los casos más conocidos. Chrome Platform Status registra Wasm en alrededor del 5,5% de las page loads de Chrome, arriba desde el 4,5% del año anterior. No es masivo, pero crece.
Edge computing. Cloudflare Workers, Fastly Compute y Wasmer Cloud ejecutan módulos Wasm con arranque en frío de microsegundos (frente a los milisegundos de los containers). Para funciones que se ejecutan en el edge cerca del usuario, esto importa.
Plugins seguros. Wasm como sandbox para código de terceros es otro caso en auge: sistemas de plugins donde el código del plugin no puede corromper el proceso host porque el motor Wasm lo aisla. Envoy Proxy y otros proxies lo usan para filtros configurables por el usuario.
JVM en el servidor. Con WasmGC, ejecutar código JVM (Java, Kotlin, Scala) en Wasm se vuelve práctico. Para los desarrolladores Java, el artículo sobre Kotlin/Wasm cubre cómo funciona en la práctica.
Las limitaciones que siguen ahí
WebAssembly no tiene multi-threading nativo en WASI. En el navegador existe la propuesta de shared memory + atomics, pero en el lado servidor Wasm todavía carece del modelo de hilos que los servicios backend dan por supuesto. No hay fecha para esto.
El toolchain para lenguajes distintos de C/C++/Rust sigue siendo irregular. Para Rust y C++ la experiencia es buena; para Python, Ruby o PHP las herramientas existen pero requieren más configuración.
Números de adopción
El 70% de los desarrolladores ya usa o evalúa Wasm fuera del navegador, según datos de la CNCF. El 67% de los nuevos proyectos empresariales incluye al menos un módulo Wasm. Son números de una encuesta, no de producción confirmada, pero indican que el ecosistema ha pasado de curiosidad a herramienta evaluada seriamente.
Imagen: Pexels / AS Photography