WebAssembly lleva años prometiendo un futuro donde el rendimiento nativo llega al navegador sin depender de JavaScript. En 2026 esa promesa ya es realidad productiva, y Rust es el lenguaje que mejor lo aprovecha. No porque sea el único que compila a WASM, sino porque tiene ventajas concretas que el resto no tienen.
Por qué Rust encaja tan bien con WebAssembly
WASM es bytecode. Cualquier lenguaje con compilador que lo soporte puede generar módulos WASM, así que la pregunta no es si tu lenguaje favorito "puede", sino qué precio pagas por usarlo.
El precio más habitual es el garbage collector. Si usas Go, C# o Java para compilar a WASM, el runtime del GC va incluido en el módulo. Eso dispara el tamaño del fichero y añade pausas de recolección en el peor momento. Rust no tiene GC: gestiona la memoria en tiempo de compilación, así que el módulo resultante contiene solo el código que escribiste.
Además, el target wasm32-unknown-unknown es Tier 1 en Rust desde hace tiempo. Eso significa que el compilador lo mantiene como ciudadano de primera clase, no como experimento. Las actualizaciones del compilador no rompen los proyectos WASM.
Y luego están las herramientas. El Rust+WASM Working Group mantiene activamente wasm-pack y wasm-bindgen, los dos proyectos que hacen que trabajar con WASM desde Rust sea cómodo de verdad.
wasm-pack: de Rust a npm en un comando
wasm-pack es la herramienta que transforma tu crate de Rust en un paquete listo para el mundo JavaScript. La instalación es la habitual:
cargo install wasm-packY el comando principal que usarás es:
wasm-pack build --target webEse comando genera una carpeta pkg/ con tres cosas: el módulo .wasm compilado, los bindings JavaScript que lo envuelven y las definiciones TypeScript para que tu editor sepa qué tipos esperar. Puedes publicar esa carpeta directamente en npm sin tocar nada más.
El caso de uso típico es implementar en Rust una función que en JavaScript sería lenta: cifrado, compresión, parsing de ficheros grandes, procesamiento de imágenes. Escribes la función en Rust, la compilas con wasm-pack y la llamas desde tu código JS como si fuera una función normal. El rendimiento es notablemente mejor porque WASM corre a velocidad casi nativa.
wasm-bindgen: el puente entre Rust y JavaScript
wasm-bindgen es la librería que hace posible pasar datos entre Rust y JavaScript más allá de números enteros. Sin ella, la comunicación entre los dos mundos se limita a i32, f64 y similares. Con ella puedes trabajar con strings, arrays, objetos y hasta promesas.
El uso básico es un atributo sobre la función o el struct que quieras exponer:
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn procesar_texto(entrada: &str) -> String {
format!("Procesado: {}", entrada.to_uppercase())
}
Ese #[wasm_bindgen] le dice al compilador que genere los bindings necesarios para que la función sea accesible desde JavaScript.
web-sys y js-sys
wasm-bindgen viene acompañado de dos crates que amplían mucho lo que puedes hacer:
- web-sys: bindings generados automáticamente para las APIs del navegador. DOM, Fetch API, Canvas, WebGL, WebSocket... todo está ahí. Si existe en el navegador, web-sys probablemente lo cubre.
- js-sys: bindings para los objetos nativos de JavaScript.
Array,Promise,Object,Date,JSON. Útil cuando necesitas interactuar con estructuras JS sin escribir los bindings a mano.
Juntos, web-sys y js-sys te permiten escribir código que accede al DOM, hace peticiones de red o manipula el canvas, todo desde Rust, sin tocar JavaScript.
Ejemplo completo: Rust llamado desde JavaScript
Veamos el flujo de principio a fin. Primero el código Rust en src/lib.rs:
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn saludar(nombre: &str) -> String {
format!("Hola, {}! Esto viene de Rust.", nombre)
}
Compilas con:
wasm-pack build --target webY en tu fichero JavaScript:
import init, { saludar } from './pkg/mi_crate.js';
async function main() {
await init(); // carga el módulo WASM
const resultado = saludar('programacion.net');
console.log(resultado); // "Hola, programacion.net! Esto viene de Rust."
}
main();
El await init() es necesario porque cargar el binario WASM es asíncrono. Una vez resuelto, las funciones exportadas se comportan como cualquier función JavaScript.
Leptos: frontend full-stack sin salir de Rust
Si wasm-pack y wasm-bindgen son para integrar Rust en proyectos JavaScript existentes, Leptos va un paso más allá: te permite escribir toda la interfaz de usuario en Rust puro, sin JavaScript.
Leptos compila a WASM para el cliente y a binario nativo para el servidor. Tiene su propia macro view! que se parece mucho a JSX:
use leptos::*;
#[component]
fn Contador() -> impl IntoView {
let (count, set_count) = create_signal(0);
view! {
<div class="contador">
<p>"Valor: " {count}</p>
<button on:click=move |_| set_count(count() + 1)>
"Incrementar"
</button>
</div>
}
}
En 2026 Leptos va por la versión 0.7, con integración directa con Axum en el servidor. El flujo es: el servidor renderiza HTML (SSR), lo envía al cliente y el módulo WASM lo hidrata. El usuario ve contenido de inmediato y después el componente se vuelve interactivo.
¿Para quién es Leptos? Para equipos o devs individuales que trabajan en Rust y prefieren no cambiar de contexto mental a JavaScript para el frontend. No es para todos, pero si ya vives en Rust, tiene mucho sentido.
Para el bundling de aplicaciones Leptos (y Rust+WASM en general) existe trunk, que hace lo que webpack hace en el mundo JavaScript pero pensado específicamente para esto. Mucho más sencillo de configurar para este caso concreto.
WASM en el servidor: Spin y WASM Components
WebAssembly no solo tiene sentido en el navegador. Fermyon Spin es una plataforma que ejecuta funciones serverless como módulos WASM, y en este contexto las ventajas sobre los contenedores Docker son bastante claras.
- Arranque en microsegundos, no en segundos. Un contenedor tarda en iniciarse; un módulo WASM arranca casi al instante.
- Tamaño en KB, no en MB. Un módulo WASM de Rust típico pesa mucho menos que la imagen mínima de Docker.
- Sandboxing por diseño. El modelo de seguridad de WASM es más estricto que el de un contenedor: el módulo no puede acceder al sistema de ficheros ni a la red sin permiso explícito.
Los WASM Components son el estándar que está emergiendo para componer módulos WASM entre sí. La interfaz wasi-http permite que un componente maneje peticiones HTTP sin saber en qué plataforma va a correr. Rust soporta el target wasm32-wasip2 para compilar a este formato:
cargo build --target wasm32-wasip2 --releaseLa idea detrás de los Components es que el módulo describe lo que necesita (acceso a HTTP, a un KV store, a un fichero) y la plataforma lo provee. Cambia la plataforma y el módulo sigue funcionando sin recompilar.
Estado de las herramientas en 2026
Un resumen rápido de qué está maduro y qué no:
- wasm-pack: estable, activo, la opción obvia para proyectos que mezclan Rust y JavaScript.
- wasm-bindgen: parte de los proyectos oficiales del Rust+WASM Working Group, actualización constante con cada versión del compilador.
- Leptos: activo y con buena comunidad. La versión 0.7 es la más madura hasta la fecha, aunque el proyecto aún evoluciona rápido y entre versiones mayores puede haber cambios de API.
- trunk: funciona bien para proyectos Leptos y similares, aunque fuera de ese nicho tiene menos uso.
- Spin + WASM Components: tecnología real y en producción en algunos casos, pero el estándar de Components todavía está consolidándose.
El punto débil que sigue siendo el debugging. Depurar código WASM es menos cómodo que depurar JavaScript, aunque los sourcemaps han mejorado mucho y la experiencia en Chrome DevTools es bastante mejor que hace dos años. Es el área donde más queda por mejorar.
Si quieres profundizar en cómo Rust está cambiando el desarrollo backend y de sistemas, échale un ojo a Rust en el cloud y backend en 2025. Y si te interesa el compilador en sí, aquí tienes las últimas novedades del compilador Rust.
Imagen: Pexels / Rashed Paykary