WASI 0.2.0 y por qué importa

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

La nueva versión WASI Preview 2 de WebAssembly se ve como un paso importante para convertir a Wasm en un runtime práctico y portátil más allá del navegador, gracias a su interfaz de sistema basada en capacidades y al modelo de componentes emergente/Canonical ABI para la interoperabilidad poliglota. Los comentaristas debaten si este enfoque es un “segundo sistema” sobredimensionado o una base necesaria para cargas de trabajo seguras de estilo serverless y sistemas de plugins, comparándolo con esfuerzos anteriores como JVM/CLR, los applets de Java y NaCl. Hay entusiasmo por usos reales (de Figma a extensiones de VS Code) y por el potencial futuro (APIs de GUI, async y GC en Preview 3), junto con frustración por piezas que faltan como gráficos estandarizados, hilos y herramientas fluidas para lenguajes como C.

APIs de gráficos y GUI

  • Varios comentaristas quieren una API estándar de GUI estilo framebuffer para WASI, de modo que las aplicaciones WASM puedan dibujar en una pantalla fuera de los navegadores.
  • Otros sostienen que los framebuffers están obsoletos y que las APIs de más alto nivel como WebGPU son mejores; contraargumento: WebGPU aún no es ubicuo y WASM se ejecuta más allá de los navegadores.
  • Contribuidores involucrados con WASI dicen que los gráficos no han sido bloqueados por los proveedores; simplemente no han tenido el foco de los contribuidores, que ha estado sobre todo en piezas sin servidor y fundamentales.
  • Hay interés en futuras propuestas de GUI/dispositivos de E/S, pero todavía no existe un estándar concreto.

Modelo de componentes, Preview 2 y compatibilidad

  • WASI Preview 2 se basa en el WebAssembly Component Model, separando el “WASM central” de las APIs de nivel superior.
  • Los módulos WASI existentes no son directamente compatibles; se necesitan adaptadores, lo que algunos ven como algo desordenado y un “efecto de segundo sistema”.
  • Otros argumentan que el modelo de componentes trata de una interoperabilidad limpia y una ABI canónica (sin exportaciones de memoria compartida, recursos basados en handles) que permite cooperar a distintos lenguajes y modelos de memoria.
  • El modelo de componentes puede usarse sin WASI y está en una ruta de estandarización, aunque todavía no esté completamente formalizado.

Qué problema resuelve WASI

  • Varias explicaciones: el WASM central por sí solo no puede hacer E/S; WASI define un sistema de interfaz basado en capacidades (archivos, redes, etc.), especialmente para runtimes no basados en el navegador.
  • Se compara con “POSIX para WASM”, aunque algunos señalan que WASIX apunta más directamente a la semántica de POSIX.
  • La seguridad basada en capacidades (permisos mínimos y explícitos) se destaca como un objetivo de diseño clave.

Casos de uso vs. escepticismo

  • Los escépticos dicen que, después de ~10 años de trabajo relacionado con WASM, ven sobre todo demos, herramientas complejas y un valor económico poco claro, especialmente en comparación con compilaciones nativas.
  • Otros citan usos prácticos: aplicaciones de navegador (herramientas de diseño, juegos, vídeo, emulación de Flash), sistemas embebidos, plugins poliglota, extensiones de VS Code y scripting de mods de juegos.
  • El WASM del lado del servidor se ve como prometedor pero todavía inmaduro; el rendimiento y el soporte de los proveedores de nube siguen siendo preguntas abiertas.

Comparaciones con JVM/CLR y applets

  • Algunos ven WASI como una repetición de ideas de CLR, JVM y esfuerzos anteriores de bytecode; el debate gira en torno a si “repetir” algo es malo si esta versión logra adopción real y es más abierta.
  • Applets vs WASM: los comentaristas enfatizan la superficie expuesta más pequeña de WASM, mejor tiempo de arranque, enfoque multilenguaje y el respaldo de una coalición de proveedores.

Políglota, FFI y funciones futuras

  • Hay un fuerte interés en una FFI poliglota más fácil; Preview 2, junto con el modelo de componentes y la ABI canónica, se ven como bases para ello.
  • Están surgiendo herramientas y marcos (por ejemplo, sistemas de plugins), pero siguen siendo limitados en tipos de datos y ergonomía.
  • Se espera que añadidos futuros como GC y async (Preview 3) hagan de WASM un mejor runtime para lenguajes como JavaScript y Dart, y mejoren la integración con motores de JS compilados a WASM.