Más allá de JavaScript: Desatando el Poder de WebAssembly para Aplicaciones Web Más Rápidas

Hola a todos. Mi nombre es Nathan, y estoy aquí hoy para hablar sobre WebAssembly. Solo una rápida muestra de manos, quiero ver quiénes aquí han oído hablar de WebAssembly o saben cómo funciona WebAssembly o cuál es la utilidad de WebAssembly. Muy bien. La razón principal por la que hago esta pregunta es porque la mayoría de los desarrolladores que he encontrado por ahí no han oído hablar de WebAssembly o incluso si han oído hablar de WebAssembly, realmente no están seguros de cómo usarlo. Sienten que es como un truco. Así que ahí es donde entro en escena.

Daré una breve demostración de 20 minutos. Veremos algunas aplicaciones del mundo real. Veremos cómo algunas otras marcas lo están haciendo en sus aplicaciones de producción. Compararemos los puntajes en JavaScript puro en React con Rust WebAssembly. Así que vamos a sumergirnos directamente en ello. Entonces, el problema es que JavaScript no fue creado para el rendimiento. En los últimos años, JavaScript ha visto muchas mejoras. El compilador justo a tiempo, la recolección de basura, todo eso realmente ha hecho de JavaScript un lenguaje fuerte.

Pero en el fondo, JavaScript no fue hecho para el rendimiento. Fue hecho para la productividad del desarrollador. Y cuando tareas como las tareas intensivas de CPU como el procesamiento de imágenes o el procesamiento de datos masivos entran en escena, JavaScript a menudo tiene dificultades. Podemos tener técnicas de optimización de imágenes, podemos tener carga diferida, memorización, división de código pero todo eso realmente ayuda con tareas relacionadas con IO, no con tareas extensivas de CPU. Y esa es la brecha exacta que WebAssembly llena o como lo llamamos WASM. Así que WASM está aquí para descargar estas tareas intensivas de CPU y realmente mostrarte el rendimiento de las ganancias de CPU con JavaScript como un.

Ahora, sé que muchos de ustedes tendrían la misma experiencia que esta persona que tienen, ustedes están escuchando sobre WebAssembly por primera vez y no están realmente seguros de por dónde empezar. Así que estén conmigo, comenzaré con lo más básico explicando qué es WebAssembly, y luego profundizaremos en algunas demostraciones prácticas.

Entonces, WebAssembly es una forma de ejecutar código rápido y de bajo nivel en sus navegadores. JavaScript es un lenguaje de alto nivel. Ahora, ¿cuál es la diferencia entre un lenguaje de alto nivel y un lenguaje de bajo nivel? Entonces, JavaScript no te da una forma de asignar dinámicamente memoria a una variable. Por otro lado, lenguajes como C, Rust, C++ te dan una forma dinámica de asignar la memoria. Correcto.

Entonces, ya que puedes asignar la memoria tú mismo, puedes utilizar más eficientemente la CPU, el poder bruto de la CPU. Los lenguajes de alto nivel, como dije, JavaScript está destinado a la productividad del desarrollador y no cuenta con esta asignación dinámica de memoria. Y ahí es donde entra WebAssembly. Actúa como un puente entre el navegador web y el código de bajo nivel. Usando WebAssembly puedes usar C, C++, Rust, todo eso en tu navegador web. El navegador web ya no está limitado solo a JavaScript.

Así que WebAssembly realiza todo el trabajo pesado de CPU y JavaScript se encarga de las interacciones del usuario y de renderizar componentes en la pantalla del usuario. Y con eso, es hora de la demostración. Sé que acabamos de hablar de como dos diapositivas sobre WebAssembly, pero quiero darte una muestra real.

Vamos al navegador web, veamos WebAssembly en acción, veamos cómo se compara con JavaScript puro. Una vez que veamos y evaluemos la diferencia real de rendimiento, entonces podremos relacionarnos mucho mejor con el código.

Así que déjame cambiar al navegador. Y déjame ejecutar una pestaña. Así que este es un archivo HTML muy básico donde verás dos botones y ambos botones tendrán una página diferente. Déjame abrir ambos en pestañas separadas.

La primera pestaña es con la versión de JavaScript puro y la segunda pestaña es con la versión de Rust y Wasm. Así que en la primera página, verás una opción para subir una imagen. Hagámoslo. Subiré una imagen y puedes ver que esta imagen es de 6.5 MBs. Así que déjame subir esto. Esta es la imagen original que hemos subido, puedes ver los colores, puedes ver que es bastante clara. Ahora hay un botón de procesar imagen en ella.

En el archivo HTML, puedo hacer clic en esto y el procesamiento comenzará y aplicaremos un conjunto de filtros predefinidos en esta imagen en particular. Déjame hacer clic en eso. Tan pronto como hago clic en él, el procesamiento ha comenzado. Tomará unos segundos procesar la imagen. Aplicaremos algo de nitidez, algo de realce de color y puedes ver las imágenes procesadas aquí ahora.

Se ve visiblemente diferente. Hemos aplicado sepia, hemos aplicado brillo suave, hemos aplicado nitidez. Hemos ajustado el contraste y todos esos filtros tomaron alrededor de 6900 milisegundos. Así que eso es aproximadamente entre seis y siete segundos. Es un tiempo enorme.

Ahora haremos lo mismo en un tipo similar de página HTML, pero utilizando Rust en WebAssembly.

La salida es exactamente similar a lo que obtuvimos en el archivo de JavaScript vanilla. El tiempo de procesamiento es de seis, tres, ocho milisegundos. Eso es menos de un segundo. En nuestro archivo de JavaScript vanilla, tomaba diez veces más realizar el mismo conjunto de operaciones. Y estos son filtros idénticos. No hay diferencia en el tipo de filtros que hemos aplicado para ambos sims.

Ahora piensa en si quisieras hacer la misma operación en 100 imágenes. Si quieres aplicar una marca de agua en 1000 imágenes o déjame cambiar a la PPT y ver. Esta es nuestra aplicación de iPhone. Permite a los usuarios elegir entre más de 15 filtros dentro de cada filtro el usuario puede arrastrar y elegir el valor de más 100 a menos 100. Y con el toque o deslizamiento de su dedo, el usuario puede ver la diferencia visible en su pantalla justo ahí. Si tenemos que dar esta experiencia al usuario en la web, será una experiencia muy complicada para JavaScript. Así que WebAssembly realmente brilla en estas tareas intensivas de CPU.

Ahora, hemos hablado mucho, hemos visto una demostración, pero nosotros como desarrolladores realmente no nos relacionamos con las cosas a menos que hayamos visto el código. Así que ahora vamos a sumergirnos en los datos del código. Estoy usando visual code data. Y veamos el archivo HTML. Así que este es el HTML de inicio donde teníamos dos botones de HTML vanilla. Y RUST si abro ambos archivos. El archivo vanilla, como puedes ver, es un archivo bastante básico que permite tiene un botón de carga un botón de proceso. Tan pronto como el usuario hace clic en el botón de proceso, comienza algún procesamiento. Está usando el archivo vanilla.js.

En el archivo de JavaScript vanilla, verás que cuando el usuario hace clic en subir imagen, hay algo de procesamiento ocurriendo. Pero cuando el usuario hace clic en el botón de procesar imagen, estos son los filtros que estamos aplicando. Ajustando el brillo, aplicando desenfoque, ajustando el contraste, resaltando color, brillo suave, CPL, todo eso. Y todos estos filtros no son más que algunos métodos de JavaScript. Solo estamos ajustando los datos de la imagen. Estamos cambiando píxeles individuales de la imagen y aplicando algunas fórmulas predefinidas específicas sobre ellos. Así que cuando queremos aplicar desenfoque a una imagen en particular, cambiamos cada píxel individual de esa imagen particular de una manera específica para que se pueda aplicar el filtro de desenfoque. Y lo mismo ocurre con los siete de estos filtros.

Ahora, veamos la misma experiencia dentro de nuestros archivos RUST. En RUST.HTML, en lugar de usar vanilla.js, estamos usando RUST.VASM.js. El RUST.VASM.js también tiene un flujo muy similar ya que tenemos los event listeners, tenemos la función de carga de imagen, tenemos el método de procesar imagen donde estamos aplicando todos los filtros. La única diferencia entre esto y el JavaScript vanilla era que en nuestro archivo de JavaScript vanilla, todos esos métodos estaban definidos dentro del archivo. Estos son métodos de JavaScript. Correcto. Mientras que en un RUST.VASM.js, todos estos métodos han sido importados y estos son importados de un paquete. Estos provienen de un proyecto RUST. Y te mostraré cómo agregué esos proyectos RUST y dónde entra en juego WebAssembly. Así que esa es la única diferencia clave.

En lugar de definir estas tareas intensivas de CPU en nuestro archivo de JavaScript, utilicé métodos basados en RUST y los usé para reducir el tiempo de cálculo. Así que esta es nuestra carpeta de filtros de imagen donde tengo mi paquete RUST. Si abro la fuente, verás un archivo RUST. Este archivo RUST tiene exactamente esos siete métodos de filtro. Y están haciendo el mismo conjunto de fórmulas, que mencioné que estamos ajustando los píxeles solo en una sintaxis RUST ahora. Así que la funcionalidad que estamos implementando es idéntica, la única diferencia es la sintaxis para el RUST. Lo clave que verás es que cada método tiene un VASM bindgen en la parte superior. Así que esto es lo que permite que los métodos RUST estén dentro para ser usados dentro de un archivo de JavaScript. Pudimos importar todos estos siete métodos porque dentro de un módulo RUST, cada uno de estos métodos tiene VASM bindgen escrito en la parte superior. En la carpeta del paquete, verás un archivo VASM, así que cada vez que construyes tu módulo RUST, veremos los comandos de construcción también. Cada vez que construyes tu proyecto RUST, verás un archivo VASM y algo de código de enlace.

Este archivo VASM es un archivo codificado en binario que no se puede abrir dentro de nuestro editor de código. Pero si vamos a nuestro proyecto. Déjame mostrarte la siguiente pestaña. Si recargo, verás en nuestra pestaña de red, este archivo VASM ha sido descargado a través de la Internet y también el glue code, que mencioné. Este glue code no es más que una forma de cómo podemos conectar métodos de JavaScript y RUST. Genial. Así que fue divertido, vimos cómo pudimos reducir el tiempo a una décima parte para hacer el mismo tipo de operaciones. También vimos cómo podríamos hacerlo usando JavaScript y RUST.

Ahora, para darte una visión general nuevamente, JavaScript carga el archivo binario VASM que vimos en nuestra pestaña de red, el JavaScript está cargando el archivo VASM y esto ha sido cargado. ¿Por qué? Déjame mostrarte nuevamente este método init. Así que estos siete métodos son los métodos que definimos, este método init es el método VASM que es proporcionado por VASM en sí. Así que este método de inicialización es lo que inicializa VASM y descarga el paquete VASM a través de Internet. Ese es el primer paso. Una vez que hemos hecho eso, entonces hay un glue code, el VASM bind gen que te mostré en el código, ese es el glue code. Actúa como un puente, inicializa el módulo VASM. Convierte los tipos de JavaScript en los tipos de VASM y permite desde un archivo RUST VASM.js llamar a esos métodos.

Cuando JavaScript llama a estos métodos exportados, el navegador puede entonces ejecutar el bytecode VASM directamente. Y lo mismo se puede implementar en React también. La única diferencia al implementar lo mismo en React es que tendrás que usar useEffectHook porque queremos inicializarlo solo durante el primer renderizado. Y se usará el mismo método init, que acabo de mostrarte cómo podemos importarlo. En useEffectInit, cada vez que el archivo VASM ha sido cargado, el archivo binario lo establecemos en estado a true, establecemos VASM listo a true para que podamos entender y consolar lo mismo. Ahora, hemos visto que la ganancia de rendimiento fue enorme, 10x. Pero ¿por qué? Entendemos que JavaScript es de alto nivel. Entendemos que VASM era de bajo nivel. Pero ¿cuál es el principio clave que está teniendo lugar para ver una brecha de rendimiento tan grande? Así que hay tres factores principales. El primero es que JavaScript es un lenguaje de alto nivel, tipado dinámicamente. Mientras que VASM es ahead of time compilation. Así que lo que quiero decir con eso es que en JavaScript, es tipado dinámicamente y hay un just in time compiler que está constantemente tratando de optimizar tu código. Trata de desoptimizar tu código. Hay recolección de basura.

Así que el procesamiento de todo el código de JavaScript es bastante grande y lleva algo de tiempo. Mientras que VASM, como se dice, es compilación anticipada. Así que en el momento de la compilación, el compilador puede predecir. Qué tipos de datos esperar, y no tiene que seguir reoptimizando tu código, eso ahorra una cantidad de tiempo bastante notable. Las variables de JavaScript son dinámicas. Por ejemplo, si has hecho let a es igual a cinco y luego puedes decir a es igual a una cadena, ¿verdad? Puedes cambiar el tipo, el tipo de datos en JavaScript y el compilador just in time tiene que mantener un seguimiento constante de esto. Pero en VASM, dado que es fuertemente tipado. No puedes tener esta actualización constante de tipos de datos y por lo tanto se puede lograr una gran cantidad de optimización de tiempo en la CPU con esto.

Y por último, pero no menos importante, los objetos de JavaScript viven en el heap de recolección de basura. Así que como mencioné, dado que JavaScript es un lenguaje de alto nivel, no tenemos el control de cuándo asignar o desalojar la memoria, el recolector de basura de JavaScript hace eso por nosotros. Mientras que en VASM utiliza memoria lineal, veamos eso en un diagrama corto. Así que como puedes ver en el pipeline de ejecución de JavaScript, el navegador primero analiza el código, intenta compilar just in time, intenta optimizarlo, luego intenta reoptimizar si entiende que los tipos de variables están cambiando, intenta ejecutar el código y en la etapa posterior intenta recolectar basura para liberar la memoria.

En WebAssembly, como puedes ver, el pipeline es mucho más simple y como resultado, mucho más rápido también. Solo tiene que decodificar y dado que en el momento de la compilación sabe y es predecible, no tiene que compilar constantemente, optimizar constantemente y reoptimizar el WebAssembly. Entonces, bueno, si estamos viendo una ganancia tan grande, ¿debería reescribir todas mis aplicaciones de JavaScript existentes en Rust? Bueno, no lo creo. Ha habido una tendencia reciente de que muchas personas están migrando sus aplicaciones existentes, aplicaciones de JavaScript a Rust, pero ese no es el mejor enfoque. Hay algunas advertencias, por supuesto. Así que la primera y mayor advertencia, el primer gran obstáculo para la adopción de VASM es que no puedes acceder directamente al DOM desde VASM.

Ya sea Rust, ya sea C, C++, dado que estos son lenguajes de bajo nivel, no entienden HTML, no tienen acceso al objeto window o al objeto document. Así que JavaScript tiene que hacer eso. JavaScript puede descargar tareas intensivas de CPU a VASM y VASM puede hacer eso. Pero la manipulación del DOM solo debe ser realizada por JavaScript. Esa es la forma sugerida.

El segundo punto sería sobre la recolección de basura. Si tenemos demasiadas llamadas entre JavaScript y VASM, podría haber un conflicto en el que JavaScript se confunda sobre cuándo recolectar basura del valor y cuándo no recolectar basura del valor. Y puede tener un efecto adverso además del tamaño binario. Si el tamaño binario de tu archivo VASM, que mostraste en la pestaña de red, si eso aumenta, eso también puede aumentar el tiempo de descarga de la pestaña de red. Así que ese tampoco es el mejor caso. Así que solo reduce el tamaño, solo úsalo donde sea necesario para obtener el impulso de rendimiento que VASM promete proporcionarte.

Figma, eBay, todos esos grandes nombres han usado y han ganado notablemente un rendimiento significativo. Estos son algunos enlaces que puedes intentar ver. He añadido algunas capturas de pantalla de Figma. Así que Figma pudo reducir su tiempo de carga en 3x. Puedes ver algunos de los gráficos también. Pudieron reducir su tiempo de carga en el navegador Firefox en 3x, y si has usado Figma en la web, verás lo fluida que es su aplicación. Están usando bastante VASM para lograr esa experiencia similar a la nativa. Así que si quieres usar VASM en tus proyectos, es muy simple.