Potenciando las aplicaciones de React con WASM

Por supuesto, como dijo Nataniel, es mi primera vez y, por supuesto, mi laptop tiene que morir y se suponía que iba a mostrar algunas demos, pero improvisaré. De todos modos, hoy, gracias por estar aquí y voy a hablar sobre cómo potenciar las aplicaciones de React con WebAssembly.

Pero primero, permítanme presentarme un poco. Mi nombre es Mukun, soy del sur de India. Soy un ingeniero de software con sede en los Países Bajos en Oortek. Anteriormente, trabajé como desarrollador backend, principalmente como programador científico, pero poco a poco comencé a hacer la transición al mundo del front-end. Bueno, fue una experiencia bastante interesante. Tengo una perspectiva única para ver todas estas diferentes tecnologías compartiendo el protagonismo, ¿verdad? En el camino, descubrí Wasm o WebAssembly. Voy a llamarlo Wasm porque es mucho más fácil.

Y me resultó bastante intrigante, siendo un desarrollador backend de profesión, se podría decir. Así que veamos la agenda. Voy a hablar sobre qué es Wasm. Voy a hablar sobre cómo funciona realmente. Y tal vez podamos hacer una breve comparación con JavaScript. Y voy a hablar sobre por qué deberías interesarte por Wasm, ¿verdad? Por qué deberías interesarte por esta nueva tecnología, relativamente nueva. Y luego también voy a estar, bueno, no voy a mostrar la demo, por supuesto, pero voy a hacer algunas aplicaciones con react. Tal vez en el stand del orador puedas ver la aplicación en funcionamiento.

Entonces, ¿qué es Wasm, o qué es WebAssembly? Es un objetivo de compilador de bajo nivel, que fue introducido por W3C. Como pueden ver, cuanto más feo es el logo, más seria es la organización. Pensé que iba a haber risas, pero está bien. Son un buen público. W3C lo introdujo en 2015, en colaboración con Google, Microsoft, Apple, Mozilla, todos los objetivos habituales. Tengan en cuenta que dije un objetivo de compilador, un objetivo de bajo nivel. Esto significa que no está destinado a ser escrito directamente por un humano, sino que está pensado como un objetivo de compilador para lenguajes fuente como Go, C++ y Rust. Pronto se unirán otros lenguajes también. Y todos ellos se pueden convertir a WebAssembly. Ahora, la filosofía de diseño de WebAssembly es hacerlo lo más compatible posible con versiones anteriores. Por lo tanto, debe funcionar con las tecnologías web existentes, y así lo hace. Esa es la filosofía de diseño para que no compita con JavaScript, sino que funcione junto con JavaScript.

Entonces, ¿por qué deberías interesarte por WASM o WebAssembly? Podrías pensar, oh, esto es solo otra tecnología.

Probablemente sea una moda. No voy a invertir mi tiempo en aprenderlo. Pero te diré que es un poco más interesante y te diré por qué. Hay tres razones. Primero, ¡zoom! Bueno, sí, funcionó mejor en mi cabeza. Pero es realmente rápido. Pero también ves un pequeño asterisco en la parte inferior, términos y condiciones. Cuando digo que es realmente rápido, me refiero a la velocidad de ejecución, lo que significa que, dado que estamos hablando de lenguajes fuente como C++, Go o Rust, estamos hablando de lenguajes compilados estáticamente, estamos hablando de compilación de antemano, ¿verdad? Por lo tanto, en cuanto a la ejecución, está configurado para funcionar a velocidades casi nativas.

El segundo es extremadamente seguro. Bueno, porque los binarios, el propio binario de Wasm, se ejecutan en la VM web, es bastante seguro, y hay algunos conceptos como sistemas de archivos y puertos que simplemente no existen en Wasm. Por lo tanto, es seguro en ese sentido. Y el tercero es que es altamente portátil. Es el estándar de la industria. Ahora, esta puede ser una opinión controvertida, pero tengo que decirte que JavaScript ya no tiene el monopolio en la web. Oficialmente, tiene que compartir el protagonismo con el objetivo de Wasm, al que se unen otros lenguajes fuente. Así de portátil es. También se puede ejecutar en diferentes arquitecturas de dispositivos o arquitecturas de procesadores. Y sí, así es como brilla la portabilidad en WebAssembly.

Entonces, echemos un vistazo más profundo a lo que realmente sucede bajo la superficie. Cuando tienes un montón de código C++ o lenguajes fuente, tienes un montón de código que no entiendes, lo envías al compilador y la mayoría de los compiladores, bueno, la mayoría de los compiladores basados en LLVM admiten el objetivo de Wasm. Ahora, si recuerdas, dije que se puede escribir en un formato WAT y tiene ensamblador en su nombre. Así que puedes imaginar que necesitas, si eres un genio y estás loco, también puedes controlar toda la ejecución y la asignación de memoria. Pero si eres tonto, si eres cuerdo y normal, como yo, simplemente lo escribes en un lenguaje fuente, ¿verdad? Luego tomas este paquete binario de Wasm y lo envías al navegador y el navegador simplemente lo ejecuta junto con todos los demás grandes lenguajes que ya conoces, que son JavaScript, CSS y HTML. Echemos un vistazo más profundo a cómo sucede este proceso cuando el navegador recibe el paquete de Wasm, ¿verdad? En cuanto a la compilación de JavaScript, puedes considerarlo equivalente a la representación intermedia. Cuando el navegador recibe el paquete de Wasm, utiliza el compilador del motor para transformarlo en código de máquina y luego este tipo de código de máquina puede interactuar con el resto de tu aplicación web a través de una capa, esta capa son las API web. Así es como se ejecuta dentro de la VM. Puede que tengas una pregunta. He estado hablando mucho sobre Wasm y cómo se compila y cómo se ejecuta. ¿Cómo lo hace JavaScript? Tal vez esto ya te resulte bastante familiar y también simplificado, pero de todos modos lo explicaré muy rápido. JavaScript se puede ejecutar en diferentes entornos, como ya sabes.

Podría ser cliente, basado en navegador, podría ser nodo, podría ser otros entornos también. Y tiene un motor detrás. O el motor es responsable de compilar el código JavaScript. Tiene diferentes partes que utiliza para compilar este código.

Entonces tomas este código JavaScript realmente malo y abultado que escribo, por ejemplo. Y luego lo envías al analizador y el analizador se encargará de escanear el código, buscando errores de sintaxis. Luego tienes el árbol de sintaxis abstracta, que es AST. Bueno, estoy seguro, lo cual está bien, porque la charla anterior fue sobre AST, así que tal vez no tenga que explicarte todo. Esta estructura de datos en particular es muy adecuada para convertirse en la etapa final, que es solo código de máquina. Esto se envía al intérprete.

El intérprete hace algunas cosas interesantes. Aquí es donde entra en juego toda la compilación en tiempo de ejecución. Me disculpo por simplificar en exceso este proceso, pero para ser breve, el intérprete produce dos salidas diferentes. Tienes el código de máquina no optimizado y tienes el código de máquina optimizado. Para que se ejecute lo más rápido posible, el intérprete genera este bytecode, que, por supuesto, por el nombre, puedes imaginar que no está optimizado, por lo que es más lento que los resultados de rendimiento que podría lograr. Pero luego, durante el tiempo de ejecución, también envía datos de perfilado o heurísticas al compilador o al perfilador. Enviaría más información al compilador para generar código de máquina optimizado. Esto se ejecuta órdenes de magnitud más rápido que el bytecode, por ejemplo. Pero luego, si la heurística o la suposición se equivoca en algún lugar, entonces se produce este proceso de desoptimización. Y esta es la principal diferencia entre este proceso y lo que hace WebAssembly.

Así que mantén esta imagen en mente. ¿Cómo se compara o contrasta con WebAssembly? Y luego boom, solo tienes el paquete wasm igualmente malo, pero optimizado que inicialmente compilaste a partir de un lenguaje fuente, y luego lo envías directamente al compilador. Ves que no hay pasos intermedios, ni relleno, por así decirlo, presente, y luego el compilador se encarga de ello y genera código de máquina optimizado. Y la palabra clave es código de máquina optimizado, porque estamos hablando de lenguajes compilados estáticamente. Aquí no ves un proceso de optimización y desoptimización en marcha. Y esa es la diferencia principal entre los dos procesos, en mi opinión.

Aquí es donde se suponía que debía mostrarte una demostración, pero simplemente repasaré los conceptos básicos de la demostración y lo que se supone que representa. Una de las demostraciones que creé en mi computadora, que existe en mi computadora, utiliza técnicas de procesamiento de imágenes. El procesamiento de imágenes, si lo sabes, implica un proceso intensivo en cómputo.

Para llevar a cabo cualquier tipo de procesamiento de imágenes, se necesita código altamente optimizado. Pero entonces, necesitas código muy optimizado, lo cual significa que típicamente no se utiliza JavaScript para crear código de rendimiento muy optimizado en términos de cómputo científico. Por lo tanto, el problema es que tienes técnicas de procesamiento de imágenes simples que debes llevar a cabo. Tienes gradaciones. Puede ser convertir la imagen a escala de grises. Puede ser agregar o cambiar los canales de color de la imagen. Entonces tienes este problema, ¿cómo lo resolverías? ¿Cómo basarías tu arquitectura de software?

Una forma es pensar inmediatamente en una arquitectura cliente-servidor, donde construyes diferentes servicios, tienes tu frontend por separado y luego tienes tu backend por separado, y puedes dejar que interactúen a través de un canal, por ejemplo, HTTP, y luego puedes construir una capa de API REST en la parte superior de tu backend para comunicarte, para exponer tu backend. Esto está completamente bien. Es bastante estandarizado y se utiliza en producción en muchos lugares, y luego también ves estas capas, pero en mi opinión, con cada capa, introduces latencia y aumentas el tiempo de respuesta. Pero estoy buscando una respuesta rápida. Estoy buscando hacer clic en un botón y obtener mi imagen procesada de vuelta. Pero eso es solo, bueno, podrías intentar lograrlo, pero hay una especie de limitación impuesta por ese canal de comunicación y también el tiempo de respuesta que toma el backend.

Lo segundo que podrías hacer o el segundo enfoque que podrías tomar es usar WebAssembly. Aquí, tomo ese backend que ves, podría estar escrito en cualquier framework o cualquier lenguaje. Típicamente, el procesamiento de imágenes es bastante popular con C++, pero en esta demostración que hice en mi computadora, que está en mi computadora, lo hice usando Rust. Entonces tomas ese backend y lo incrustas, por así decirlo, en tu cliente y de esa manera, bueno, eliminas esa marca de flecha en particular, que típicamente representa la capa de comunicación HTTP. Lo tienes todo en tu navegador, ¿verdad? Así que, si vuelvo a la diapositiva, ahora voy a seguir el segundo enfoque, tomaré el enfoque del lado del cliente y también tomaré la opción lista para usar, ya tengo el paquete, no tengo que preocuparme por la implementación. Bueno, el enfoque de implementación. Utilicé la biblioteca Wasm llamada Photon, está completamente escrita en Rust, todo el crédito va para la autora, Sylvia O'Dwyer, pero también tuvo la cortesía de crear un paquete Wasm a partir de ella, por lo que todo lo que necesito hacer es importar el paquete Wasm y luego usar las funciones para mis necesidades de procesamiento de imágenes. Así de simple. Aquí iba a mostrar la demostración, iba a mostrarte el procesamiento de imágenes diferentes, solo imagínalo en tu cabeza y tal vez pueda mostrártelo fuera de la sala. Entonces, la segunda forma es, por supuesto, la forma de Wasm. Aquí ves que es tan simple como importar el paquete Wasm y luego, por ejemplo, si quieres aplicar un desenfoque gaussiano, que es algo que harías para procesar la imagen, simplemente llamas a la función y obtienes la imagen procesada como salida. Bueno, la segunda demostración es, bueno, la demostración o la aplicación que hice, utiliza una técnica de aprendizaje automático y, bueno, si conoces el aprendizaje automático, utiliza mucho álgebra lineal, mucha optimización matemática. Nuevamente, es un proceso muy intensivo en cómputo, ¿verdad? Así que en esta aplicación intenté predecir el objetivo utilizando una variable objetivo, utilizando múltiples características. Utilicé un conjunto de datos donde hay diferentes acciones, bueno, utilicé el conjunto de datos donde hay una acción de la empresa durante un año y predije utilizando diferentes características que son como el precio de apertura, el precio de cierre, el precio mínimo y el precio máximo. Hago esto a través de una regresión lineal, si hay algún científico de datos en esta sala, por favor no me mates porque esta es una forma terrible de predecir acciones. Entonces, en esta aplicación utilicé dos frameworks diferentes, por supuesto. Utilicé un paquete de instalación npm, aunque no lo creas, fue bastante difícil encontrar un paquete adecuado que me permitiera llevar a cabo la regresión lineal. Y también utilicé un paquete Wasm que escribí utilizando Rust, pero no te preocupes también utilicé el paquete de Ciencia de Datos en Rust para hacer esto.

Y los resultados fueron bastante interesantes. Cuando lo probé con 100 puntos de datos, los resultados fueron desequilibrados, porque cronometré las funciones, cronometré las funciones de ajuste del modelo y cuando solo usé 100 puntos de datos, parecía que el paquete wasm fue completamente superado por el paquete de instalación de npm. Y hay algunas razones para esto, porque cuando hablas de wasm, no es solo que obtienes una velocidad de ejecución muy buena, sino que también tienes toda esta sobrecarga adicional, porque si recuerdas, te dije que el paquete wasm necesita un código azul de JavaScript y solo puede interactuar con el resto de la aplicación web utilizando APIs. Esa es la sobrecarga que generalmente ocurre cuando se usan paquetes wasm. Pero luego, algo bueno es que si aumento o ajusto el conjunto de datos, tal vez aumente la densidad de los puntos de datos de, digamos, 100 puntos a 20,000 puntos, ahora veo resultados comparables. Veo que los tiempos de ejecución son muy comparables a los de JavaScript. Ahora bien, el punto es que no quiero, bueno, no puedo demostrarlo de manera concluyente porque no puedo mostrar la demostración, pero el punto que estoy tratando de hacer es que ya puedes usar la gran cantidad de bibliotecas que ofrece C++ , Rust ofrece, lo cual supera con creces el panorama de NPM cuando se trata de aplicaciones científicas. Así que hay una verdadera ventaja de usar bibliotecas maduras, bibliotecas que ya están construidas para ti. Así que tal vez no reinventes la rueda.

Entonces, para reiterar, ¿por qué usarías WebAssembly? ¿Por qué te importaría? La ventaja más importante que veo es que puedes usar código heredado. Puedes reutilizar código heredado. Un ejemplo en la industria es que eBay utilizó código heredado de C++ para implementar la función de escaneo de códigos de barras en su aplicación web. Así que ese es un muy buen ejemplo, ¿verdad? Porque tienes algo que puedes usar en tus aplicaciones del lado del cliente, pero no para tus aplicaciones web. Hay múltiples ejemplos de este tipo cuando ves Google Earth, cuando ves AutoCAD. Todas esas aplicaciones heredadas se han trasladado al mundo de las aplicaciones web. Y la segunda ventaja es que es portátil. Nuevamente, una opinión controvertida. JavaScript no es el único lenguaje en el que puedes programar para la web. Ahora también hay otros lenguajes. Y luego puedes apuntar a diferentes arquitecturas, a arquitecturas ARM, a la arquitectura x86. Y la última es la informática en el borde. Con la introducción de WASM, puedes aumentar el alcance de las funciones que puedes llevar a cabo con CDNs inteligentes. Y esto es muy importante porque hay muchas funciones muy complejas que antes solo se delegaban en centros de datos de alto rendimiento o muy costosos. Pero ahora también pueden ser realizadas por una variedad de dispositivos. Y eso, creo, es un logro muy bueno. Estas son las ventajas y eso es todo por ahora. Y estaré encantado de responder cualquier pregunta. Y gracias por escuchar. Me impresionó, déjame decirte eso.

Ese fue un tema intenso en el que te adentraste, eres muy valiente. Y el hecho de que lo hayas manejado como un profesional, es increíble. Voy a agarrar rápidamente las preguntas y respuestas, que olvidé completamente obtener. Si tienes preguntas, veamos. Muy bien. Tenemos la primera pregunta, que es, ¿cuándo debería un desarrollador elegir WASM, W-A-S-M, sobre JavaScript y viceversa? ¿Cuándo lo elegirías? Como dije, si tienes mucho código heredado en tu empresa, y si estás tratando de, bueno, usarlo como un modelo de caja negra, software de caja negra, entonces es genial. Si estás tratando de migrar a la web, es una excelente opción usar WebAssembly, y tampoco es tan difícil revisar tu código. Genial, muy bien. Ahora, sé que algunas personas quizás vayan a una de las otras charlas rápidamente. ¿Les importaría mantener sus voces bajas para que las personas que hacen preguntas puedan obtener sus respuestas? Muchas gracias.

Muy bien. Increíble. Tenemos otra pregunta de alguien que quiere mantenerse en el anonimato. ¿Sería bueno usar WASM para compartir una biblioteca centralizada de componentes de interfaz de usuario en proyectos escritos en diferentes lenguajes? ¿Así que tener una biblioteca de componentes esencializada con componentes construidos en diferentes lenguajes? Esa es una buena pregunta. Aunque no estoy seguro si se pueden construir componentes completos utilizando WebAssembly. Porque esa es una de las grandes desventajas de WebAssembly es que realmente no tiene APIs para acceder al DOM. Y de esa manera, estás limitado en esa área. Pero, por supuesto, aún está en desarrollo. Sí. Mucho más por venir. Mucho más por venir. Y también, ¿tienes acceso al DOM con WASM? ¿Puedes escribir? Supongo que esta es en realidad una pregunta muy, muy similar, ¿verdad? ¿Tienes acceso al DOM o necesitas llamarlo a través de JavaScript? Bueno, no tienes acceso directo al DOM. Y, por supuesto, sí, tienes acceso indirecto a JavaScript. Sí, tiene sentido. Mientras hacía la pregunta, podía escucharla.

¿Cuáles son los ejemplos de WASM en la práctica? Sé que mencionaste tal vez Google Earth y algunos otros. ¿Hay otros ejemplos destacados? Hay muchas startups que están utilizando bibliotecas de Rust, especialmente bibliotecas criptográficas, directamente en sus aplicaciones web. Creo que es un campo muy interesante. Y sí, AutoCAD es una aplicación de ingeniería que solía ser exclusivamente para el cliente. Y ahora está disponible en la web. Me encanta. Me encanta ver cómo algunas de estas cosas realmente grandes que eran muy pesadas, ahora pueden ser más accesibles para más personas. Además, otro ejemplo destacado es Figma, que también utiliza no lo sabía. Hoy aprendí. Hoy aprendí.

OK, otra pregunta para anónimo. Dado que estamos omitiendo el paso de optimización utilizando WASM, ¿perderíamos las optimizaciones de tiempo de ejecución entonces? ¿O simplemente estamos omitiendo la optimización inicial? No estoy seguro de qué optimización debería ser esa bastante si recuerdo correctamente. En tu caso, tenías uno con todos los diferentes pasos, y luego el código no estaba optimizado al principio. Y luego estaba bien, optimizar y volver a optimizar. Pero ahora, en el siguiente, cuando mostraste, ¿estamos omitiendo ese paso de optimización? Estoy tratando de interpretar la pregunta. Lo siento. ¿Estamos omitiendo ese inicial o todavía estamos haciendo optimización de tiempo de ejecución? Bueno, como mencioné, realmente no tienes el ciclo de optimización, desoptimización. Pero también depende del lenguaje fuente que uses. Si usas, por ejemplo, C++ o Rust, ya es bastante rápido y no cuentan con un recolector de basura como tal. Por lo tanto, el rendimiento es bastante rápido desde el principio. Y esa es la principal razón por la que no necesitas el paso de desoptimización. Genial. Ahora, como todos los desarrolladores sabemos, solo somos tan buenos como nuestras herramientas. Y este se trata de la depuración. ¿Cuál es la historia de la depuración al utilizar WASM en el navegador? ¿Cómo se hace la depuración? No se puede. Es un tema muy difícil. Es algo que probablemente necesitas ejecutar el paquete localmente incluso para depurar. Por ejemplo, si has escrito una biblioteca en Rust, debes ejecutarla localmente para depurarla. Las herramientas de depuración del navegador para paquetes WASM no están desarrolladas o no son tan maduras como te gustaría que fueran. Esperemos que, tal vez el próximo año, puedas venir aquí a hablar sobre la depuración de WASM. Ese ya es tu título. Mi computadora finalmente funciona. Genial. Genial. Genial. No te preocupes. Lo tendremos listo. Esta viene de Mike. ¿Mediste la diferencia de rendimiento al usar JS versus usar WASM para la aplicación de procesamiento de imágenes? Sé que era una de las demostraciones que querías mostrar, pero ¿tienes algún número o algún tiempo en mente sobre la diferencia en rendimiento? Bueno, no he medido el tiempo para eso. Bueno, no he medido el rendimiento para el procesamiento de imágenes. Pero si vas a la wiki de la biblioteca de procesamiento de imágenes, Photon, dice que han realizado extensas pruebas de referencia. Y son un 30 por ciento más rápidos que sus contrapartes en C++. 30 por ciento. Eso es asombroso. Aplaudamos a Makun una vez más. Gracias, gente. Gracias a todos por compartir.