WebAssembly escapó del navegador. En 2026, se está convirtiendo silenciosamente en el runtime para todo

Cuando WebAssembly se lanzó en 2017, la propuesta era directa: un formato de instrucción binario que los navegadores podían ejecutar a velocidades casi nativas, permitiendo aplicaciones que JavaScript por sí solo no podía manejar. Figma portó su motor de renderizado a WASM y logró que un software de diseño complejo fuera viable en el navegador. AutoCAD Web lo usó para ejecutar código C++ de décadas de antigüedad sin reescribir nada. El caso de uso en navegadores era real y la tecnología cumplió.

Lo que nadie predijo del todo fue que los usos más trascendentales de WebAssembly ocurrirían completamente fuera del navegador.

Cómo WASM escapó del sandbox

El desarrollo clave fue WASI (WebAssembly System Interface), propuesto por Bytecode Alliance en 2019 y que alcanzó una especificación estable 2.0 en 2024. WASI proporcionó a los módulos de WebAssembly una interfaz estandarizada para interactuar con el sistema anfitrión: leer archivos, hacer conexiones de red, acceder a variables de entorno. Esto suena mundano, pero tuvo una implicación profunda: un módulo WASM compilado con soporte WASI podía ejecutarse en cualquier lugar donde existiera un runtime WASI, no solo en un navegador, sino en un servidor, en el edge, en un dispositivo IoT, dentro de un motor de base de datos.

Solomon Hykes, el creador de Docker, dejó clara la importancia en un post que se volvió ampliamente citado: "Si WASM+WASI hubiera existido en 2008, no habríamos necesitado crear Docker. Así de importante es." La promesa era un binario universal portable: compilar una vez, ejecutar en cualquier lugar, con un sandbox de seguridad integrado.

Dónde se ejecuta WASM en 2026

Edge computing y funciones serverless. Cloudflare Workers ha soportado WASM desde 2018, pero en 2026 es el runtime principal para funciones críticas de rendimiento en el edge. Fastly Compute, Fermyon Spin y Wasmer Edge ejecutan cargas de trabajo WASM en nodos edge distribuidos globalmente. El atractivo es una combinación de tiempo de arranque (inicios en frío de menos de un milisegundo, frente a 50–200 ms para una función Node.js), aislamiento de seguridad (cada módulo se ejecuta en su propio sandbox con concesiones de capacidad explícitas) y portabilidad (desplegar el mismo binario en cualquier proveedor).

Extensibilidad de bases de datos. SingleStore, DuckDB y otras bases de datos ahora soportan funciones definidas por el usuario escritas como módulos WASM, permitiendo que lógica personalizada se ejecute dentro del motor de consultas con acceso a operaciones vectorizadas y sin la sobrecarga de un viaje de ida y vuelta a un proceso externo. El soporte de UDF WASM en PostgreSQL, estabilizado en 2025, abrió esta capacidad a la base de datos de código abierto más ampliamente desplegada del mundo.

Sistemas de plugins. Zed (el editor de código), Extism (un framework de plugins utilizado por decenas de aplicaciones) y un número creciente de herramientas de desarrollo usan WASM como su runtime de plugins. La ventaja sobre los sistemas de plugins nativos tradicionales es el aislamiento: un plugin que se comporta mal no puede bloquear el proceso anfitrión ni acceder a recursos fuera de sus concesiones de capacidad. Este es el modelo que Shopify usa para sus extensiones de aplicación personalizadas y que Figma utiliza para su ecosistema de plugins.

CLI portátiles y herramientas. El modelo de componentes WASM (estandarizado en 2024) habilitó la composición: puedes construir una herramienta CLI como un conjunto de componentes WASM que importan y exportan interfaces tipadas, y luego componerlos independientemente del lenguaje en el que fueron escritos originalmente. Un componente en Rust puede llamar a la interfaz de un componente en Python sin que ninguno conozca el lenguaje de implementación del otro. Esto está permitiendo una nueva generación de herramientas agnósticas al lenguaje.

El modelo de componentes cambia el cálculo

El modelo de componentes WASM merece atención especial porque resuelve un problema que ha plagado el software políglota durante décadas. Anteriormente, si querías llamar a una librería escrita en Rust desde Python, tenías que lidiar con FFI, memoria compartida, sobrecarga de serialización o llamadas a subprocesos. El modelo de componentes reemplaza todo esto con un lenguaje de definición de interfaz (IDL) seguro en tipos y agnóstico al lenguaje (WIT — WebAssembly Interface Types) que los compiladores de Rust, Python, JavaScript, Go, C y otros pueden usar como destino.

El resultado es que un desarrollador puede escribir una librería de procesamiento de cadenas de alto rendimiento en Rust, exponerla como un componente WASM con una interfaz WIT tipada y llamarla desde Python sin código repetitivo de FFI. El binario se ejecuta en un sandbox, la interfaz se verifica en tipos en el límite, y el mismo componente funciona en cualquier lugar donde exista el runtime WASM.

Lo que aún falta

El crecimiento de WASM fuera del navegador viene con limitaciones genuinas. El soporte de recolección de basura (garbage collection) solo alcanzó estado estable en 2024, lo que anteriormente lo hacía incómodo para lenguajes como Python y Java que dependen de GC. Los hilos y la memoria compartida funcionan pero tienen salvedades en torno a las operaciones atómicas que varían según la plataforma. La historia de las herramientas ha mejorado drásticamente — existen wasm-pack, cargo-component y componentize-py — pero la experiencia aún va por detrás del desarrollo nativo en términos de depuración, perfilado y mensajes de error.

El rendimiento es casi nativo para trabajo limitado por CPU, pero no para cargas de trabajo que dependen en gran medida de los servicios del sistema operativo: la E/S de archivos a través de WASI es más lenta que la nativa, y las concesiones de seguridad del modelo de capacidades añaden sobrecarga en comparación con las llamadas directas al sistema. Para caminos críticos de latencia, estas brechas importan.

La trayectoria

La línea de tendencia es clara. Wasmtime (mantenido por Bytecode Alliance) se está integrando en todo, desde proveedores de nube hasta herramientas CLI y bases de datos. El modelo de componentes está ganando adopción más rápido que cualquier especificación WASM anterior. Los proveedores de navegadores están alineados en características futuras como recolección de basura, cambio de pila para corutinas y mejoras en el manejo de excepciones.

WebAssembly no reemplazará los contenedores ni los binarios nativos para todas las cargas de trabajo. Pero para los casos de uso específicos donde importan la portabilidad, el aislamiento de seguridad y los tiempos de arranque inferiores a un milisegundo — funciones en el edge, aplicaciones extensibles, herramientas portátiles, plugins en sandbox — ya se ha convertido en la opción predeterminada. Los próximos cinco años de su desarrollo probablemente lo harán irreconocible en comparación con el formato binario centrado en el navegador con el que empezó.