- WebAssembly (Wasm) sigue usándose como tecnología clave en diversos productos reales, y cumple un papel importante en motores de videojuegos, herramientas de diseño y contenedores web
- El lenguaje en sí tiene una estructura que se mapea eficientemente al hardware y está diseñado con foco en la seguridad y la portabilidad
- Su modelo de seguridad tiene una estructura de “denegar por defecto” (deny-by-default), lo que permite aislamiento a nivel de proceso y ejecución rápida
- Se aprovecha en distintos entornos gracias a su ecosistema de plugins y soporte multiplenguaje, pero todavía no tiene una adopción al nivel de reemplazar por completo al navegador
- Actualmente, WebAssembly está profundamente integrado a nivel de bibliotecas y runtimes, y es una tecnología cuya estandarización y expansión funcional avanzan con rapidez
Casos de uso reales
- WebAssembly cumple funciones clave en Godot, Figma, Stackblitz, Squoosh.app, Zellij y Ruffle
- Godot lo usa para compilaciones de juegos para la web, y Figma para convertir código C++ en una forma ejecutable dentro del navegador
- Stackblitz aprovecha Wasm para contenedores web, y Ruffle como emulador de Flash
- Sin embargo, son pocos los sitios grandes construidos por completo sobre Wasm; en la mayoría de los casos se usa para funciones específicas
Qué es WebAssembly y de dónde viene su velocidad
- WebAssembly es un lenguaje, y su velocidad no es una propiedad intrínseca, sino que depende del rendimiento del motor
- Igual que con JavaScript, el motor de ejecución en tiempo real (V8, SpiderMonkey, etc.) determina la velocidad de ejecución
- WebAssembly tiene una estructura que se mapea eficientemente al hardware moderno, y puede ejecutarse tanto compilado como interpretado
Estructura de mapeo eficiente
- Wasm es un bytecode cercano al lenguaje ensamblador, que puede compilarse para la mayoría del hardware sin pérdidas
- WAT (WebAssembly Text) es la representación textual de Wasm, y permite una conversión casi 1:1
- Es similar al bytecode de la JVM, pero con una API pequeña y fuertes garantías de seguridad
- El acceso a memoria es explícito, y solo pueden usarse los recursos permitidos por el entorno anfitrión
Wasm como objetivo de compilación
- Diversos lenguajes como Rust, C, Zig, Go, Kotlin, Java y C# pueden compilarse a Wasm
- Incluso lenguajes interpretados como Python, PHP y Ruby pueden ejecutarse mediante builds para Wasm
- Los navegadores incluyen por defecto un motor de Wasm, y también existen runtimes independientes como Wasmtime, WasmEdge y Wasmer
- Un único artefacto Wasm puede ejecutarse de forma independiente del hardware
Estructura de seguridad y usos
- WebAssembly adopta un modelo de seguridad de “denegar por defecto”, donde el acceso externo solo se permite mediante imports explícitos
- Su pila de control de flujo oculta, memoria lineal y conjunto limitado de instrucciones garantizan un aislamiento sólido
- Cloudflare aísla la ejecución de código basado en Wasm usando isolates de V8, y Fermyon ofrece tiempos de arranque de nivel submilisegundo
- Ruffle restaura contenido Flash de forma segura, Pyodide ejecuta Python sobre Wasm, y Figma ejecuta plugins con QuickJS basado en Wasm
Portabilidad e integración embebida
- Los runtimes de Wasm son livianos, y Zellij, Envoy y Lapce adoptaron Wasm para sus sistemas de plugins
- Incluso en entornos con motor de JavaScript, pueden usarse diversas bibliotecas Wasm para procesamiento de imágenes, OCR, motores físicos, renderizado, toolkits multimedia, bases de datos y parsers
- En la mayoría de los casos, el usuario ni siquiera nota que se está usando Wasm, porque opera de forma transparente dentro de la biblioteca
Revisión de velocidad y tamaño
- Los navegadores ejecutan Wasm con el mismo pipeline que JS, por lo que existen límites de rendimiento derivados de la arquitectura del motor
- La eficiencia varía según el sistema de tipos del lenguaje y el nivel de optimización del compilador
- Se señalan como desventajas el costo del límite entre host y programa y el aumento del tamaño del binario
- El estándar WASI busca aliviar esto, pero la estandarización del tipo string todavía no está terminada
- Zig genera los binarios Wasm más pequeños
- En entornos nativos, el rendimiento puede degradarse por threading, IO y uso de memoria
Tendencias en el desarrollo del lenguaje y los estándares
- La estandarización de Wasm avanza en paralelo entre el grupo de trabajo del W3C y Bytecode Alliance
- Esta última lidera desarrollos centrados en herramientas como WIT y Component Model
- Las propuestas de nuevas funciones se adoptan con rapidez, y en algunos sectores hay debate sobre la velocidad y la dirección que está tomando
- Wasm se expande más como tecnología de integración interna que como reemplazo de JavaScript
- Frameworks como Blazor y Leptos aprovechan Wasm sin manejar JS directamente
- Actualmente, Wasm es adoptado sobre todo por creadores de bibliotecas, y los desarrolladores generales pueden usarlo sin conocer su funcionamiento interno
- La dificultad del material educativo se señala como una barrera de aprendizaje, y se menciona el proyecto educativo
watlings
1 comentarios
Comentarios de Hacker News
Creo que Wasm logró en gran medida los objetivos que tenía cuando fue creado
En lo personal, usé Wasm como componente central en decenas de proyectos
Los motores de JS son muy rápidos, pero Wasm todavía ofrece un mayor nivel de control sobre la CPU y un rendimiento excelente
Aun así, no cumplió con la expectativa de reemplazar por completo a JS+HTML+CSS. Creo que una gran razón es la falta de bindings para el DOM
También probé frameworks de Wasm como Yew, pero se sentían como una capa incómoda montada encima de JS
Todavía no he usado Blazor, pero sigo sintiéndome más cómodo escribiendo en JS
De todos modos, Wasm está funcionando silenciosamente en muchos lugares, y creo que esa es la verdadera prueba de su éxito
Por ejemplo, la función de cambiar velocidad y tono del audio en el navegador logra un nivel de rendimiento que solo es posible ejecutando una librería de C++ en Wasm
Si aparecen bindings adecuados para el DOM, JS será desplazado del frontend en menos de 10 años
C# facilita compartir código entre backend y frontend, y las plantillas Razor también tienen buen soporte en el IDE
Pero hay que cargar completos el .NET CLR y la BCL, así que el tamaño del bundle es grande
Como el acceso al DOM es difícil, Blazor tiene una estructura con un pequeño renderizador de Virtual DOM del lado de JS
El rendimiento es aceptable, pero sigue siendo más lento que JS escrito directamente
Bolero, basado en F#, también es interesante, pero es difícil convencer al equipo
Para interactuar con el DOM hace falta un lenguaje de alto nivel adecuado para eso
JS cumple bien ese papel, y la combinación HTML/CSS/JS ya se volvió el lenguaje común del desarrollo de interfaces
Hay intentos de abandonar el renderizado del navegador e irse por la vía de canvas, pero siguen siendo un nicho
Sería terrible vivir en un mundo donde incluso un sitio web simple obligue a descargar un runtime de varios MB
La causa real de la lentitud no es JS, sino el DOM. Al final hay que interactuar con el DOM de todos modos
Trabajé varios años con WebAssembly y pronto voy a publicar un framework basado en Wasm
El ecosistema avanzó rápido y luego de repente se desaceleró, mientras la adopción de WASI y del Component Model generó confusión
El nivel de soporte varía entre motores, así que muchas veces uno termina saltando entre documentación, código y issues
El problema más grande es el soporte para JS/TS. Hoy por hoy es una integración casi a base de hacks, así que no es estable
Web Containers trajeron algunas mejoras, pero muchos desarrolladores ya se pasaron a Bun
El potencial de Wasm es enorme
En teoría, podría convertirse en el objetivo de compilación común para todas las plataformas
Pero en la realidad, termina siendo algo así como una forma de hacer más rápido parte de Figma, y eso resulta algo decepcionante
También es una limitación que el desarrollo, al estar centrado en comités, avance lentamente
En la época de Native Client se podían hacer apps a velocidad nativa, pero ahora Wasm es más lento que eso
Habría sido bueno poder aplicar también a Wasm la estructura de bindings de JS
Además, Wasm ni siquiera es más rápido que JS
HTML/CSS/JS ya demostró su utilidad, mientras que Wasm sigue siendo un stack tecnológico desconocido para muchos
El ecosistema centrado en Docker está frenando las cosas
Muchas herramientas de build del ecosistema JS están escritas en Rust, y algunas se ejecutan en el navegador mediante Wasm
React y el ecosistema de npm también usan Wasm internamente
Si Wasm desapareciera, el mundo del frontend en JS se sacudiría bastante
Aun así, los frameworks de UI nativos para Wasm todavía son escasos
Hay que depender del DOM y de CSS, y acceder a las APIs del navegador a través de JS, lo que es ineficiente
Se puede controlar el DOM con Rust o Kotlin, pero Rust es demasiado de bajo nivel para frontend
La compilación cruzada móvil está aumentando cada vez más, y JetBrains Compose Multiplatform es un ejemplo de eso
Lo que frena el avance de Wasm es el tooling
Depurar sigue estando al nivel de
printf, y el plugin DWARF de Chrome lleva mucho tiempo sin actualizarseEl proceso de generar archivos .wasm por lenguaje y configurar import/export es complejo
El soporte de GC tampoco está completo, así que ecosistemas como .NET tienen que cargar su propio GC
WIT parece otro intento más al estilo de COM/CORBA/gRPC
Emscripten es complejo e inestable, y wasi-sdk tiene pocas funcionalidades
Tanto LLVM como los motores siguen flojos en optimización, y el tooling de Wasm en Rust está prácticamente detenido
Ni siquiera existe una forma estándar de importar módulos Wasm desde JS
El soporte de multihilo también exige configurar headers COOP/COEP, lo que lo vuelve imposible en GitHub Pages
Si el tooling hubiera pasado del nivel de “demo técnica”, se usaría mucho más
Nuestra empresa, Leaning Technologies, usa Wasm de forma muy activa
Con WebVM ejecutamos binarios x86 en el navegador,
con BrowserCraft corremos apps Java (incluyendo Minecraft),
y con BrowserPod ponemos en marcha contenedores Node.js en el navegador
Es muy potente, pero es una herramienta para usuarios avanzados. Compilar lógica general de frontend a Wasm es ineficiente
También dijeron que impresiona la velocidad de avance de CheerpJ, y que si hubiera aparecido 10 años antes, la plataforma web podría haber sido distinta
Desde la postura de quienes odian JS, el verdadero atractivo de Wasm es hacer un sitio web sin JS
Trabajo en Dioxus, un framework de Wasm basado en Rust
En el frontend con Wasm, el problema era la falta de herramientas básicas como división de bundles, hot reload, símbolos de depuración e integración de assets
En 2025 eso mejoró bastante, y la integración con herramientas como Vite también avanzó
Gracias a las herramientas de IA, la velocidad de desarrollo en Rust también mejoró, y espero que los frameworks Wasm reciban más atención en adelante
Hubo críticas sobre el tamaño binario de Wasm, que sería demasiado grande
En entornos con DSL, la descarga puede tardar de varios segundos a varios minutos
Se argumenta que JS es más pequeño y además puede ejecutarse mientras se descarga
Si se compila con Rust, puede reducirse a un rango de 10~100KB
JS no se ejecuta durante la descarga, y Wasm puede arrancar más rápido gracias a la compilación en streaming
Al final, terminan reimplementando funciones que el navegador ya ofrece
Por ejemplo, FSHistory implementa emulación x86 en solo 24KB
El problema es que el ecosistema nativo no está acostumbrado a optimizar el tamaño del código
Mi experiencia no coincide con lo que dice el artículo de que “no existen grandes sitios web hechos con Wasm”
El objetivo de los proyectos Wasm nunca fue reemplazar toda la webapp
Parece que la gente se hizo expectativas equivocadas y ahora pregunta “¿por qué eso no pasó?”
En la práctica sí apliqué Wasm en varios casos reales
Se puede resolver cortando desde el backend solo la parte necesaria