WebAssembly salió del navegador. Ahora se ejecuta en Shopify, Cloudflare y tu clúster de Kubernetes.
WebAssembly se lanzó en 2017 como solución a un problema del navegador: JavaScript era demasiado lento para código crítico en rendimiento, y los plugins nativos resultaban demasiado peligrosos. La respuesta fue un formato binario compacto capaz de ejecutar código casi nativo dentro de un entorno de navegador aislado: de forma segura, portable y rápida. Funcionó. Editores de vídeo, herramientas CAD y simulaciones científicas se trasladaron a la web. El rendimiento de Figma se triplicó al migrar su motor de renderizado a C++ compilado a WASM.
Entonces ocurrió algo inesperado. Los ingenieros empezaron a preguntarse si un formato binario rápido, aislado y agnóstico en cuanto al lenguaje podría ser útil en algún lugar que no fuera un navegador. La respuesta fue sí, y el ecosistema que ha crecido en torno a esa respuesta ahora es lo suficientemente maduro como para usarse en producción.
El Component Model: la pieza que faltaba y llegó
La especificación original de WebAssembly tenía una limitación fundamental para el uso en servidor: dos módulos WASM compilados desde diferentes lenguajes no podían llamarse entre sí sin código de gestión de memoria manual propenso a errores. Una librería Rust y un servicio Go vivían en espacios de memoria separados sin un sistema de tipos compartido. Esto hacía impracticables las arquitecturas políglotas componibles.
El WebAssembly Component Model, estabilizado en 2025, resuelve esto con una interfaz binaria de aplicación compartida y un lenguaje de descripción de interfaces agnóstico llamado WIT (WebAssembly Interface Types). Un archivo WIT declara qué funciones y tipos de datos exporta o importa un componente, sin suposiciones de memoria específicas del lenguaje. El toolchain (wit-bindgen, wasm-tools, jco) genera el código de integración automáticamente. El resultado práctico: un parser Rust de alto rendimiento, un pipeline de Machine Learning en Python y un frontend TypeScript pueden componerse como componentes WASM sin FFI escrito a mano. WASM 3.0 fue ratificado como estándar W3C en septiembre de 2025, incorporando garbage collection, memoria de 64 bits, SIMD relajado y manejo de excepciones junto con el Component Model.
WASI: la capa de interfaz que hace realidad la portabilidad
Ejecutar WASM fuera del navegador requiere una forma de que el módulo interactúe con el sistema anfitrión: leer archivos, abrir sockets de red, escribir en la salida estándar. WebAssembly System Interface (WASI) define estas APIs en un modelo de seguridad basado en capacidades: un módulo solo obtiene el acceso que se le concede explícitamente en el momento de la instanciación. Nada más es accesible.
WASI 0.2, lanzado en enero de 2024, estableció la línea base estable de producción: E/S de archivos, sockets de red e integración con el Component Model. WASI 0.3, que añade soporte nativo asíncrono con primitivas de stream y future tipadas, estaba completando los trabajos de especificación a principios de 2026. La versión 1.0, la primera «estable para siempre», está prevista para finales de 2026 o principios de 2027. La trayectoria ofrece a los autores de librerías un ABI estable al que apuntar y a los operadores una hoja de ruta clara sobre lo que cubrirán eventualmente las garantías de portabilidad.
Donde ya existen despliegues en producción
El punto de prueba más concreto a gran escala es Shopify Functions. Desde 2022, Shopify permite a desarrolladores externos personalizar la lógica de checkout, descuentos y envíos mediante módulos WASM que se ejecutan dentro de un runtime diseñado específicamente en la infraestructura de Shopify. Cada módulo se ejecuta dentro de un presupuesto estricto de 5 milisegundos; las latencias reales medidas suelen oscilar entre 0,8 y 2,5 milisegundos. Los desarrolladores escriben en Rust, JavaScript (a través del compilador Javy de Shopify, que empaqueta un motor V8 reducido en un binario WASM), Zig o TinyGo. El límite de seguridad es importante: el código de comerciantes no confiable se ejecuta en producción a escala Shopify sin acceso a los recursos del sistema anfitrión. No ha ocurrido ningún escape del sandbox. En junio de 2026, el sistema Scripts heredado que Functions reemplazó ha sido retirado por completo.
En el lado de edge computing, Fastly Compute@Edge es un entorno de ejecución puramente WASM que ofrece micromilisegundos de cold start para procesamiento de peticiones en el borde de la red. Cloudflare Workers admite módulos WASM y agregó soporte para contenedores en junio de 2025 para cargas de trabajo híbridas. La señal más significativa de la industria llegó a finales de 2025 cuando Akamai adquirió Fermyon, la compañía detrás del framework Spin para microservicios serverless WASM, y puso Fermyon Wasm Functions en disponibilidad general en el edge distribuido globalmente de Akamai en noviembre de 2025. Cuando el CDN más grande del planeta adquiere una empresa serverless WASM, la apuesta por el futuro de la tecnología es institucional, no experimental.
El panorama de runtimes
Cuatro runtimes dominan diferentes casos de uso. Wasmtime, la implementación de referencia de Bytecode Alliance, alcanzó el estatus de Proyecto Principal en abril de 2025 y ofrece alrededor del 82% del rendimiento nativo en benchmarks de cómputo. Es la opción predeterminada para WASM en servidor de propósito general. Wasmer 6.0, lanzado en abril de 2025, afirma un 95% de rendimiento nativo e introdujo Edge.js, que ejecuta aplicaciones Node.js dentro de un sandbox WASM, un interesante puente para equipos con infraestructura Node existente. WAMR (WebAssembly Micro Runtime) está orientado a dispositivos embebidos e IoT, funcionando en hardware con tan solo 256 kilobytes de memoria al 80-90% de rendimiento nativo con compilación AOT. WasmEdge está optimizado para cargas de trabajo de AI y se integra con Docker Engine como shim de contenedor junto a Wasmtime.
El enfoque de Docker es deliberado: «WASM y contenedores», no «WASM versus contenedores». Docker Engine incluye shims nativos para Wasmtime y WasmEdge, por lo que los módulos WASM pueden desplegarse con comandos docker run estándar desde un Dockerfile scratch. El toolchain converge en lugar de competir. SpinKube, un proyecto de CNCF basado en el framework Spin de Fermyon, convierte a WASM en un tipo de carga de trabajo de primera clase en Kubernetes, desplegable junto a pods de contenedores con las mismas primitivas de orquestación.
El argumento de seguridad
El modelo de seguridad de WASM es «denegar por defecto» a nivel binario. Un módulo no tiene acceso alguno al sistema anfitrión a menos que el anfitrión le conceda explícitamente una capacidad específica en el momento de la instanciación. Esto es arquitectónicamente diferente de los contenedores, que comparten el kernel del anfitrión y dependen del aislamiento de namespaces y cgroups para limitar lo que una carga de trabajo puede alcanzar. En WASM, el sandbox se impone en el runtime, independientemente del lenguaje en que se haya compilado el módulo.
Para plataformas multiinquilino, como el modelo de Shopify donde cientos de miles de comerciantes despliegan código personalizado, esta es la característica que hace viable la arquitectura. La alternativa es revisar cada pieza de código de terceros antes del despliegue, lo cual no es factible a escala. El sandbox WASM elimina la categoría de riesgo en lugar de gestionarla.
La imagen honesta del rendimiento
WASM en runtimes de servidor se ejecuta aproximadamente entre el 75% y el 95% de la velocidad nativa en cargas de trabajo intensivas en cómputo: cifras creíbles para la mayoría de los casos de uso, con salvedades. Las operaciones que involucran enteros de 128 bits y ciertos primitivos criptográficos son de 2 a 7 veces más lentas que las nativas. Las cargas de trabajo ligadas a E/S no obtienen un beneficio significativo; la ventaja está en el cómputo. Los cold starts son de 1 a 5 milisegundos, en comparación con 50 a 500 milisegundos para contenedores: este es el número que hace que WASM sea convincente para despliegues serverless y edge donde la latencia de cold start afecta directamente la experiencia del usuario.
El tiempo de desarrollo es genuinamente mayor. Construir en Rust para WASM requiere comprender la gestión de memoria y un flujo de depuración diferente al que están acostumbrados la mayoría de los desarrolladores web. El Component Model y el toolchain de WASI han mejorado significativamente, pero la depuración a través de la frontera del lenguaje sigue siendo más difícil que depurar dentro de una pila monolingüe. El ecosistema está aproximadamente donde estaba JavaScript en los primeros años de Node.js: potente, productivo y requiere inversión para usarlo bien.
La pregunta «¿debería usar WASM en lugar de contenedores?» tiene una respuesta más clara en 2026 que hace dos años: use WASM cuando la latencia de cold start sea importante (edge y serverless), cuando necesite ejecución aislada de código no confiable, o cuando quiera composición de componentes agnóstica al lenguaje. Use contenedores cuando necesite un entorno Linux completo, amplia compatibilidad de librerías o acceso a GPU. Use ambos cuando su carga de trabajo tenga capas que se beneficien de cada uno, que es cada vez más para lo que está diseñado el toolchain de infraestructura.