Web Assembly

Salgado Covarrubias José Antonio, Ortiz Navarro Sergio Bernardo, Lopez Godoy Ariadna Guadalupe, García Franco Vicente Alexis
Instituto Tecnológico de Tijuana, Tijuana, México.

jose.salgado@tectijuana.edu.mx, sergio.ortiz@tectijuana.edu.mx, ariadna.lopez@tectijuana.edu.mx,  vicente.garcia16@tectijuana.edu.mx 

^[1] 

Web Assembly.

Resumen— En los últimos años ha surgido la necesidad de contar con aplicaciones web cada vez más complejas, esto debido a las necesidades actuales y claro que para cada necesidad que surge a través de los años también coexiste o son creadas nuevas tecnologías que respectivamente satisfagan estas necesidades actuales, como lo son en estos últimos años las aplicaciones web progresivas o componentes web, que permiten solucionar el problema de crear aplicaciones web complejas, aunque queda una incógnita que estas nuevas herramientas no pueden resolver, y esto es aplicaciones web que tengan un alto rendimiento en cpu, como lo son videojuegos, renderizados, edición de video etc, este tipo de aplicaciones hasta tiempos actuales son muy complicadas para correr en la web, para esta problemática la 3WC a impulsado a Web Assembly, que es un pequeño lenguaje intermediario de bajo nivel posible de interpretarse en navegadores web, prometiendo un mejor desempeño en comparación que JavaScript. La presente investigación muestra una retrospectiva de la introducción de web assembly a la web en estos años en comparación a JavaScript, y el futuro que le depara a Web Assembly en la web y el impacto que podría tener en un futuro cercano.

1. Introducción

Web Assembly o WASM por sus siglas es un pequeño lenguaje intermediario de bajo nivel que es posible de interpretarse en navegadores web. Prometiendo un mejor desempeño en comparación que JavaScript puro.

A grandes rasgos WASM es un lenguaje de bajo nivel pensado para mejorar el rendimiento de aplicaciones web. Otra de las características adicionales de WASM es que está pensado poder transcompilar código de lenguajes de alto nivel no necesariamente para la web, a código Web Assembly, que este si se podría ejecutar en un navegador web, por ejemplo generar un módulo de una aplicación escrita en C y transcompilarla a WASM y este módulo podría ser importado como cualquier otro componente de JavaScript y ejecutarse en la web.

1. Problema

Durante años, los ingenieros que trabajan en los motores de JavaScript en los navegadores se han centrado en dos etapas clave de la ejecución de JavaScript en el navegador. Primero, es el tiempo que lleva compilar el JavaScript en un código de máquina o código de bytes (si se interpreta). Y segundo en la optimización del JavaScript compilado para que se ejecute más rápido.

Cada motor de JavaScript adopta un enfoque diferente para compilar la fuente de JavaScript. Si un motor compila la fuente sin hacer mucha optimización a medida que avanza, el tiempo de inicio es más rápido pero el código inicialmente se ejecuta más lento. Si se optimiza a medida que se compila, el tiempo de inicio es más lento.

Hay muchas limitaciones relacionadas con JavaScript. Por ejemplo, no hay tipos de datos binarios reales en la especificación del lenguaje. Claro, los navegadores han implementado matrices binarias mecanografiadas, pero esos son tipos de objetos y métodos de biblioteca en lugar de estar especificados en el lenguaje.

1. propuesta

La idea es que este lenguaje sea el “lenguaje de destino” de la compilación de otros lenguajes (Vea Fig. 1)

[pic 1]

Fig 1. Como funciona Web Assembly.

Además, WASM no es bytecode (código intermedio, al estilo de .NET IL o Java Bytecode), sino lineal y de ejecución en la pila (registros), o basado en Static Single Assignment Form (SSA). Podríamos decir que es una representación binaria de un Árbol Sintáctico Abstracto (AST), que es uno de los pasos previos que un compilador realiza.

Por si esto fuera poco, carece de versiones (tal y como se hace en la web actualmente, se comprobará la existencia de una característica que queramos usar, y no de si hay cierta versión en el entorno de ejecución), y probablemente, pueda conducir a la construcción de una auténtica “Máquina Virtual Universal”.

La parte universal viene, especialmente, de la idea de que, cuando empiece a implementarse en distintas plataformas, se podrá usar con cualquier lenguaje (C#, Java, C/C++), si bien se espera que las primeras implementaciones sean sobre C/C++. Así podremos contar con “mapas de código”, muy útiles en el proceso de depuración.

1. Objetivos

• Ser una mejora para JavaScript.
• Poder soportar varios lenguajes de programación.

1. Marco teórico

1. Antecedentes

Para comprender mejor porqué Web Assembly es tan importante, examinemos brevemente la historia de la web con un enfoque en el impacto de JavaScript en ella.

En los primeros días, la web era estática (read: basada exclusivamente en texto) y HTML era el idioma dominante para la creación de sitios web. Mocha, que más tarde se convirtió en el JavaScript de hoy en día, fue creado para permitir la interactividad y el dinamismo en la web, por lo que las animaciones y los eventos de entrada de los usuarios ahora eran posibles. Sin embargo, en este momento, JavaScript era increíblemente lento y no fue hasta 2008 (casi 13 años después de la invención de JS) que se realizaron mejoras significativas en el rendimiento de los navegadores a través de los compiladores Just in Time (JIT).

Estos compiladores aumentaron el rendimiento de JavaScript en un orden de magnitud y superaron los límites de lo que era posible ejecutar en el navegador. Sin embargo, este aumento en el rendimiento gracias a los compiladores JIT fue de corta duración ya que los desarrolladores comenzaron a poner JavaScript en el servidor (un ejemplo: Node.js) Y ampliaron aún más las limitaciones del motor de JavaScript.

Además, los fabricantes de dispositivos creaban dispositivos de alta fidelidad cada vez más complejos, como auriculares de realidad virtual que exigían velocidades de representación más rápidas y capacidades de navegador desafiadas. Si la web continuará con su trayectoria actual, correría el riesgo de perder la red nativa mucho más rápida y confiable.

...