WASM, la nueva tecnología CGI

Wasm es el nuevo CGI

• El papel de Wasm: Wasm (WebAssembly) está listo para impulsar una nueva transformación en el modelo de aplicaciones web. Su enfoque está en facilitar la creación y el mantenimiento de aplicaciones de alto rendimiento.
• Modelo anterior de aplicaciones web: CGI transformó la web de un archivo de documentos a una red de aplicaciones. FastCGI se desarrolló para resolver problemas de rendimiento y luego evolucionó hacia la computación serverless.
• Computación serverless: La computación serverless, como Amazon Lambda, hace que se administren “funciones” en lugar de servidores. Esto ofrece la ventaja de escalar rápidamente según el volumen de solicitudes.

Wasm en el servidor

• Escalabilidad de Wasm: Wasm puede ejecutarse no solo en el navegador, sino también en el servidor, lo que proporciona un modelo de aislamiento más liviano para las aplicaciones del lado del servidor.
• Entorno de ejecución de Wasm: Los módulos de Wasm se ejecutan en una máquina virtual y pueden compilarse desde diversos lenguajes. Esto puede contribuir a mejorar el rendimiento en entornos serverless.

Trade-offs de Wasm

• Hilos y compilación JIT: Wasm no admite hilos de forma predeterminada y no permite compilación JIT. Esto puede afectar el rendimiento.
• Interfaz de memoria: El movimiento de datos entre los módulos de Wasm y el host puede requerir copias, lo que puede afectar el rendimiento.

Perspectivas futuras

• Evolución de Wasm: A medida que evolucionen los entornos de ejecución de Wasm y las herramientas de desarrollo, los lenguajes de scripting pasarán a contar con runtimes de Wasm. Esto podría mejorar significativamente la velocidad de ejecución de las aplicaciones.
• Edge computing: Wasm permite realizar cómputo cerca del usuario mediante edge computing, lo que mejora el rendimiento.

# Resumen de GN⁺

• Wasm está impulsando una nueva transformación en el modelo de aplicaciones web, facilitando la creación y el mantenimiento de aplicaciones de alto rendimiento.
• La combinación de computación serverless y Wasm reduce la complejidad de administrar servidores y ofrece la ventaja de escalar rápidamente según el volumen de solicitudes.
• Wasm puede ejecutarse no solo en el navegador, sino también en el servidor, lo que proporciona un modelo de aislamiento más liviano para las aplicaciones del lado del servidor.
• La evolución de Wasm puede hacer que los lenguajes de scripting cuenten con runtimes de Wasm, mejorando significativamente la velocidad de ejecución de las aplicaciones.
• Mediante edge computing, permite realizar cómputo cerca del usuario, lo que mejora el rendimiento.

[GN⁺]

Comentarios de Hacker News

• Amazon inició la era de la computación serverless con Lambda. Google App Engine se lanzó 6 años antes que Lambda.

• Es difícil entender la diferencia entre WASM y tecnologías anteriores como Java Applets, ActiveX, Silverlight y Macromedia Flash. Pensé que ya habíamos aprendido la lección sobre ejecutar código compilado no confiable de terceros en el navegador web.

• La compilación JIT es imposible porque, por motivos de seguridad, no se permite la generación dinámica de código WASM. Esta es una capacidad esencial para hacer limpiamente cosas como la recarga en caliente del código.

• Creo que los argumentos de seguridad no son confiables. Se puede recargar JS en caliente o generar código en tiempo de ejecución, y también se puede recargar dinámicamente el runtime de WASM para conservar la memoria, pero la experiencia de usuario sería incómoda.

• No he encontrado una razón por la que sea técnicamente imposible. Si es una medida de seguridad, sería fácil de eludir.

• El bytecode de WASM es conceptualmente similar a .NET IL, Java bytecode y otros diseñados para compilación JIT.

• Creo que al proyecto WASM le falta una dirección clara y voluntad de éxito. Todavía le faltan funciones básicas.

  • Entre ellas: recarga en caliente, threading sin hacks, interfaz nativa con el DOM, soporte para APIs gráficas/de cómputo de bajo overhead y acceso de bajo nivel al audio.

• WASM reemplaza la VM de un lenguaje específico por una VM de propósito general. Eso permite ejecutar casi cualquier cosa con un compilador o intérprete.

  • Normalmente se implementa como parte de un motor de JavaScript, por lo que hereda el sandboxing y el acceso a APIs. La estandarización sigue en curso.

• A WASM se le presenta como reemplazo de JavaScript, de Docker, de Java, de CGI, etc. Es todo.

• Creo que WASM debería poder hospedarse y desplegarse tan fácilmente como una aplicación PHP. Probablemente todavía no sea así.

• Esto recuerda una vieja ley del software: una aplicación suficientemente grande y antigua termina reimplementando toda la pila de software sobre la que corre.

• La gran promesa de WASM del lado del servidor es ofrecer una plataforma eterna que no requiera actualizaciones periódicas.

  • Tener que actualizar y volver a desplegar una app de AWS Lambda cada vez que una versión de Node.js o Python deja de estar soportada es un gran problema.

• Creo que lo local-first es el futuro. La app se ejecuta principalmente dentro del navegador del usuario y casi no necesita ayuda del servidor.

  • Apps como Figma, Linear y Superhuman están usando este modelo con éxito.

• WASM puede tener éxito en el navegador del usuario. Microsoft lo está usando para C#/Blazor.

• Parece que estamos reinventando la JVM y su ecosistema.

• Creo que WASM va camino a reemplazar el código de ejecución de funciones lambda en la nube.

  • WASM se percibe tradicionalmente como algo que corre sobre una plataforma anfitriona, pero no necesariamente tiene que ser así.

  • Gracias a las propiedades de sandbox de WASM, puede ejecutarse fuera del sistema operativo o en ring0.