WebAssembly y Rust: el código que corre en cualquier lugar del planeta

Cuando usas Figma en el navegador o un coche autónomo decide frenar, hay código ejecutándose a una velocidad que el modelo tradicional de servidores no puede alcanzar. El modelo serverless clásico —donde el código vive en un servidor centralizado y tarda en arrancar— siempre fue su punto débil. WebAssembly (Wasm) y Rust están cambiando eso: el código arranca en microsegundos, corre de forma segura y se ejecuta cerca del usuario, donde sea que esté.

La nube funciona hoy sobre contenedores —cajas de software que empaquetan el código junto con el sistema operativo que necesita para correr. Son útiles, pero pesadas. WebAssembly propone algo diferente: ejecutar el código directamente, sin esa capa de emulación, como si fuera una aplicación nativa pero con las ventajas de la web.

Un contenedor Docker básico con Alpine Linux pesa alrededor de 10 MB. El mismo código compilado a WebAssembly ocupa apenas 2 MB. No es solo una cuestión de espacio: significa que un servidor físico puede ejecutar miles de funciones Wasm al mismo tiempo, activándolas y apagándolas casi sin costo.

El tiempo de arranque de un módulo Wasm es comparable al de un handshake TLS —el saludo que hace tu navegador al conectarse a un sitio seguro—: prácticamente imperceptible. Para dispositivos con memoria y energía limitadas, como los que se usan en Edge Computing, esto cambia completamente las reglas del juego.

Cada módulo WebAssembly corre en un sandbox —una celda de aislamiento— que por defecto no puede acceder al sistema de archivos, a la red ni al reloj del sistema. Para hacer cualquier cosa fuera de esa celda, el anfitrión debe conceder permisos explícitos a través de WASI (WebAssembly System Interface). Piénsalo como un contrato de arrendamiento: el módulo solo puede usar lo que está escrito en el contrato.

Esto evita que una vulnerabilidad en una función comprometa todo el servidor, y reduce significativamente los riesgos de ataques a la cadena de suministro de software.

WebAssembly ya no es solo teoría. Empresas que mueven millones de usuarios lo tienen en producción.

Fastly construyó su plataforma Compute@Edge sobre WebAssembly usando el motor Wasmtime, desarrollado por la Bytecode Alliance. El resultado: tiempos de arranque inferiores a 350 microsegundos. La lógica del servidor puede ejecutarse en un nodo cercano al usuario —sin el retraso de consultar un centro de datos al otro lado del mundo.

Cloudflare Workers hace algo similar con V8 isolates y aprovecha Wasm para soportar lenguajes como Rust y Go, logrando un rendimiento en tareas de cómputo intensivo que JavaScript solo no podría alcanzar.

Figma movió su motor de renderizado de C++ a WebAssembly dentro del navegador. Eso le permite hacer cálculos matemáticos complejos y manipular vectores en tiempo real directamente en el cliente, con un rendimiento cercano al nativo. Con JavaScript puro, esa experiencia habría sido lenta y frustrante. Con Wasm, es fluida.

Rust se convirtió en el compañero natural de WebAssembly por una razón concreta: no tiene recolector de basura —el mecanismo que otros lenguajes usan para liberar memoria automáticamente, pero que añade peso al binario y genera pausas impredecibles. En lenguajes como Java, ese recolector debe incluirse dentro del propio módulo Wasm, inflando su tamaño. Rust gestiona la memoria en tiempo de compilación, generando binarios pequeños, directos y predecibles. Ideal para microservicios que deben arrancar rápido y consumir lo mínimo.

La respuesta corta es no. Pero el transfondo es más interesante.

JavaScript sigue siendo el rey del DOM y de las interfaces de usuario. WebAssembly brilla en lo que JavaScript hace mal: procesamiento de imágenes, criptografía, motores de juegos, simulaciones físicas. El futuro más probable es una arquitectura híbrida donde JavaScript maneja la lógica de negocio y la interacción con el usuario, mientras Wasm actúa como el motor de alto rendimiento debajo del capó. No compiten: se complementan.

El ecosistema Wasm fuera del navegador todavía está madurando. Estándares críticos como el soporte completo de sockets en WASI o la gestión concurrente avanzada siguen en fases de propuesta o implementación preliminar. Para tareas donde el cómputo no es el cuello de botella, JavaScript sigue siendo la opción más práctica y el cambio no justifica el esfuerzo.

Quedar atrapado en un proveedor de nube es uno de los mayores riesgos para cualquier arquitectura. WebAssembly ofrece una salida concreta: un módulo Wasm puede ejecutarse en cualquier entorno que tenga un motor compatible —Wasmtime, Wasmer o WasmEdge, entre otros—.

Si mañana decides cambiar de Cloudflare a Fastly, o de AWS a tu propio servidor, el módulo sigue funcionando sin tocar una línea de lógica de negocio. Solo cambias el adaptador de despliegue. Eso es libertad arquitectónica real.

Los centros de datos consumen entre el 1% y el 1,25% de la electricidad mundial. Cada contenedor innecesario y cada máquina virtual sobredimensionada contribuyen a esa cifra. Al eliminar las capas de virtualización y ejecutar código de forma más eficiente, WebAssembly reduce directamente la huella de carbono de las aplicaciones serverless. Menos ciclos de CPU desperdiciados significa menos energía consumida, menos calor generado y menos infraestructura necesaria.

No hace falta reescribir toda la infraestructura de un día para otro. La adopción gradual es la estrategia más efectiva y la que menos riesgo implica:

WebAssembly nació en 2015 como una forma de acelerar el navegador. Hoy es la base de una internet más rápida, más segura y más eficiente energéticamente.

La nube del futuro no es una gran sala de servidores en algún lugar del mundo: son millones de módulos pequeños ejecutándose cerca de donde se necesitan, sin fricciones ni desperdicio. Si trabajas en desarrollo de software, el momento de entender este cambio no es mañana. Es ahora.