Blog

¿Por qué todo el mundo está hablando de WebAssembly?

Si aún no has oído hablar de WebAssembly, pronto lo conocerás. Es uno de los secretos mejor guardados de la industria, pero en realidad está en todas partes. Está respaldado por todos los principales navegadores, y también está llegando al lado del servidor. Es rápido e incluso se está utilizando para los videojuegos. Es un estándar abierto del Consorcio de la World Wide Web (W3C), la principal organización internacional de estándares para la web.

» ¡Wow!», puedes pensar, «esto parece algo en lo que debería aprender a programar!» Tendrías razón, pero también te equivocas; no se programa en WebAssembly. Tomémonos un tiempo para aprender sobre la tecnología que a menudo se abrevia en inglés como «WASM».

¿De dónde viene Web assembly?

Retrocediendo unos diez años, hubo un creciente reconocimiento de que el ampliamente usado JavaScript no era lo suficientemente rápido para muchos fines. JavaScript era sin duda útil y práctico. Se ejecutaba en cualquier navegador y permitía el tipo de páginas web dinámicas que hoy en día damos por sentado. Pero era un lenguaje de alto nivel y no fue diseñado pensando en cargas de trabajo de alta carga computacional.

Sin embargo, aunque los ingenieros responsables de los principales navegadores web estaban generalmente de acuerdo sobre el problema de rendimiento, no estaban alineados sobre qué hacer al respecto. Surgieron dos bandos. Google comenzó su proyecto de Cliente Nativo y, más tarde, su variante de Cliente Nativo Portátil, para centrarse en permitir que los videojuegos y otros programas escritos en C/C++ se ejecuten en un compartimento seguro dentro de Chrome. Mozilla, mientras tanto, se ganó el respaldo de Microsoft para asm.js, un enfoque que actualizó el navegador para poder ejecutar un subconjunto de instrucciones de JavaScript de bajo nivel muy rápidamente (otro proyecto permitió la conversión de código C/C++ en estas instrucciones).

Dado que ninguno de los dos bandos logró una adopción generalizada, las distintas partes acordaron unir sus fuerzas en 2015 en torno a una nueva norma denominada WebAssembly que se basaba en el enfoque básico adoptado por asm.js. En la Web de hoy, el JavaScript del navegador traduce esas instrucciones a código máquina. Pero con WebAssembly, el programador hace mucho del trabajo anterior en el proceso, produciendo un programa que está entre los dos estados. Eso libera al navegador de mucho del trabajo duro de crear el código de la máquina, pero también cumple la promesa de la Web: ese software se ejecutará en cualquier dispositivo con un navegador sin importar los detalles de hardware subyacentes.

En 2017, Mozilla lo declaró un producto mínimamente viable y lo sacó de la vista previa. Todos los principales navegadores lo habían adoptado a finales de ese año. En diciembre de 2019, el Grupo de Trabajo de la Asamblea Web publicó las tres especificaciones de la Asamblea Web como recomendaciones del W3C.

WebAssembly define un formato de código binario portátil para programas ejecutables, un lenguaje de ensamblado textual correspondiente, e interfaces para facilitar las interacciones entre dichos programas y su entorno de hospedaje. El código de WebAssembly se ejecuta dentro de una máquina virtual de bajo nivel que imita la funcionalidad de los muchos microprocesadores sobre los que se puede ejecutar. Ya sea a través de la compilación o la interpretación Just-In-Time (JIT), el motor de WebAssembly puede funcionar casi a la velocidad del código compilado para una plataforma nativa.

¿Por qué tienen tanta relevancia ahora?

Sin duda, parte del reciente interés en WebAssembly proviene de ese deseo inicial de ejecutar un código de computación más intensivo en los navegadores. Los usuarios de ordenadores portátiles, en particular, están pasando cada vez más tiempo en un navegador (o, en el caso de los Chromebooks, básicamente todo el tiempo). Esta tendencia ha creado una urgencia en torno a la eliminación de las barreras para ejecutar una amplia gama de aplicaciones dentro de un navegador. Y una de esas barreras es a menudo algún aspecto del rendimiento, que es para lo que WebAssembly y sus predecesores fueron concebidos originalmente.

Sin embargo, WebAssembly no es sólo para navegadores. En 2019, Mozilla anunció un proyecto llamado WASI (WebAssembly System Interface) para estandarizar la forma en que el código de WebAssembly interactúa con los sistemas operativos fuera del contexto de un navegador. Con la combinación del soporte de los navegadores para WebAssembly y WASI, los binarios compilados podrán ejecutarse tanto dentro como fuera de los navegadores, a través de diferentes dispositivos y sistemas operativos, a velocidades casi nativas.

La baja sobrecarga de WebAssembly lo hace inmediatamente práctico para su uso más allá de los navegadores, pero eso es discutiblemente lo que está en juego; obviamente hay otras maneras de ejecutar aplicaciones que no introducen cuellos de botella en el rendimiento.

¿Por qué usar WebAssembly, específicamente?

Una razón importante es su portabilidad. Lenguajes compilados ampliamente usados como C++ y Rust son probablemente los más asociados con WebAssembly hoy en día. Sin embargo, un amplio rango de otros lenguajes compilan o tienen sus máquinas virtuales en WebAssembly. Además, mientras que WebAssembly asume ciertos prerrequisitos para sus ambientes de ejecución, está diseñado para ejecutarse eficientemente en una variedad de sistemas operativos y arquitecturas de conjuntos de instrucciones. Por lo tanto, el código de WebAssembly puede programarse utilizando una amplia gama de lenguajes y ejecutarse en una gran variedad de sistemas operativos y tipos de procesador.

Otra ventaja de WebAssembly se deriva del hecho de que el código se ejecuta dentro de una máquina virtual. Como resultado, cada módulo de WebAssembly se ejecuta dentro de un entorno de caja de arena, separado del tiempo de ejecución del host mediante técnicas de aislamiento de fallos. Esto implica, entre otras cosas, que las aplicaciones se ejecutan de forma aislada del resto de su entorno de host y no pueden eludir el sandbox sin pasar por las API adecuadas.

WebAssembly en acción

Un ejemplo es la Unity. ¿Recuerdas que mencionamos al principio del artículo que WebAssembly se usa para videojuegos? Bueno, Unity, el motor de juego multiplataforma, fue uno de los primeros en adoptar WebAssembly, proporcionando la primera demostración de WASM ejecutándose en los navegadores, y, desde agosto de 2018, ha utilizado WebAssembly como objetivo de salida para el objetivo de construcción de Unity WebGL.

Otro ejemplo es Velneo. Desde la versión 28 ya es posible programar en cualquiera de los navegadores principales con nuestra plataforma de desarrollo, y en los venideros meses podremos también ejecutar nuestros desarrollos en Web. Si quieres más información puedes asistir a cualquiera de nuestros talleres de programación o ponerte en contacto.

Estas son solo algunas de las formas en que WebAssembly ya ha comenzado a tener impacto. Puedes ver más y mantenerte al día con todas las cosas de WASM en https://webassembly.org/.