Perdiendo de vista el propósito de WebAssembly

Artículo original ↗ Discusión en Hacker News ↗

El papel de WebAssembly en la pila web está en disputa: algunos lo ven principalmente como una forma de crear aplicaciones de navegador en lenguajes distintos de JavaScript, mientras que otros sostienen que su verdadera promesa está en ser un bytecode de bajo nivel y sandboxed para plugins, edge computing y binarios multiplataforma más allá del navegador. Los comentaristas debaten sus limitaciones en el navegador hoy —especialmente la necesidad de pasar por JavaScript para acceder al DOM, la complejidad de las herramientas y los grandes runtimes— junto con características emergentes como Wasm GC y el modelo de componentes, que buscan mejorar la interoperabilidad y el rendimiento. También hay tensión entre el poder y la seguridad de los módulos opacos compilados y la pérdida de la transparencia de “view source” que históricamente hizo que la web fuera fácil de aprender y trastear.

Para qué es “WebAssembly”

  • Un bando sostiene que la principal ventaja hoy es escribir aplicaciones web en lenguajes distintos de JavaScript/TypeScript.
  • Otros dicen que eso ya era posible mediante compilación a JS (asm.js, ClojureScript, GWT, etc.), así que por sí solo es una mejora incremental.
  • La visión más “emocionante” ve WASM como una capa de cómputo/sandbox general, segura y portátil: plugins, edge compute, IoT, dependencias nativas seguras, etc.

WASM vs JavaScript en la Web

  • Muchos desarrolladores quieren que WASM reemplace a JS para poder usar sus lenguajes preferidos tanto en el cliente como en el servidor.
  • Otros consideran que JS está bien o incluso es potente, y que los problemas están más en el ecosistema/herramientas que en el lenguaje central.
  • Un patrón práctico recurrente: mantener JS como “andamiaje” o pegamento y descargar las rutas críticas o bibliotecas pesadas a WASM.

DOM, APIs del navegador y herramientas

  • En los navegadores, WASM no puede usar directamente el DOM ni la mayoría de las APIs web; debe llamar a funciones host de JS como capas de adaptación.
  • Con reference types y Wasm GC, pasar referencias opacas del host (por ejemplo, nodos DOM) se vuelve más fácil y eficiente, pero sigue requiriendo pegamento.
  • Se está desarrollando un modelo de componentes y WebAssembly Interface Types (WIT) para estandarizar una interoperabilidad más rica, pero el progreso es lento y complejo.
  • Algunos se quejan de toolchains pesadas, runtimes de lenguaje grandes y la dificultad de hacer cosas como code-splitting y optimización del tiempo de arranque.

Opacidad, “view source” y accesibilidad

  • Existe una fuerte preocupación de que WASM vuelva opaca la web: los binarios compilados son más difíciles de entender que HTML/JS, lo que socava la cultura de “view source” y el aprendizaje casual.
  • Otros replican que el JS minificado ya es opaco y que mejores herramientas podrían exponer el código fuente de WASM de forma similar.
  • Las aplicaciones WASM centradas en canvas corren el riesgo de ofrecer mala accesibilidad (lectores de pantalla, selección de texto, maquetación de texto internacional) salvo que se haga un esfuerzo adicional y se usen bibliotecas.

Comparaciones con otros bytecodes y novedad

  • Algunos dicen que WASM es “solo otro bytecode” como JVM/CLR y que no justifica el entusiasmo.
  • Otros destacan diferencias: de más bajo nivel, agnóstico al lenguaje, especificado formalmente con validación verificada por máquina, fuerte sandboxing, capacidades ambientales mínimas.

Adopción, casos de uso y escepticismo

  • Ejemplos citados: aplicaciones web complejas (herramientas de diseño, visores tipo Earth, juegos de Unity, C#/Blazor) ya usan WASM de forma efectiva.
  • Los escépticos argumentan que, después de casi una década, WASM sigue sin tener una “killer app” clara y dominante en la web (sin DOM directo, threading torpe, mucho pegamento) y cuestionan si una capa universal de cómputo es necesaria o prudente.