¡Deja respirar al hilo principal!

Microsoft Mechanics www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com Hola, hablemos de cómo podemos posponer algunas tareas desde el hilo principal a otros hilos y permitir que el hilo principal respire un poco. En realidad, la razón por la que escribí esta charla fue hace unos dos años cuando estaba investigando cuántas personas en todo el mundo están conectadas a Internet. Descubrí que alrededor del 50% de la población está conectada. Y cuando volví a revisar las estadísticas, me di cuenta de que después de aproximadamente uno o dos años, cinco personas más de la población ahora están conectadas más de lo que estaban hace dos años. Y curiosamente, alrededor del 90% de estas personas están conectadas a Internet a través de sus teléfonos móviles. Es decir, simplemente están visitando nuestro sitio web, nuestra aplicación web a través de sus teléfonos móviles.

Y cuando hablo de teléfonos móviles, me refiero a una gran cantidad de teléfonos diferentes. No solo se trata de teléfonos de buena calidad como el iPhone o teléfonos de alta gama con hardware de alta calidad. También hay algunos teléfonos que se ven bien, muy bien, pero cuyo hardware no es tan potente como los teléfonos como el iPhone, por ejemplo.

Por ejemplo, el Nokia 2. Así que las personas se conectan con estos teléfonos, eso es seguro, y enviamos nuestra aplicación compleja a ellos todos los días. De hecho, cuando se trata incluso de computadoras de escritorio, tenemos diferentes laptops con diferentes especificaciones y diferentes computadoras de escritorio con diferentes hardware. Y de vez en cuando, cuando enviamos nuestra aplicación compleja, mostramos esta página no responsiva a nuestro usuario, lo que los frustra mucho. A ellos no les gusta ver estas páginas no responsivas o poco confiables. Pero nos damos cuenta de que debemos hacer algo, ¿por qué debemos preocuparnos? Entonces, ¿qué debemos hacer? La cuestión es que debemos preocuparnos por todos nuestros usuarios. Debemos preocuparnos por todos los dispositivos. Debemos preocuparnos por todos los que están conectados, incluso si estamos enviando una aplicación para un mercado local, por ejemplo, aún hay algunos, ya sabes, probablemente necesites obtener algún estatus, pero aún hay algunos, ya sabes, dispositivos que debes cubrir y soportar.

En esta charla, voy a explorar dos opciones que tenemos en los navegadores en este momento. Una subestimada, los Web Workers, y una nueva, Web Assembly, y ver cómo podemos transferir algunas de nuestras lógicas a estos hilos y liberar nuestro hilo principal para que nuestro usuario esté más feliz.

Permítanme presentarme. Mi nombre es Majid Hajji y estoy basado en Oslo. Soy un apasionado ingeniero de software. Trabajo mucho con JavaScript y frontend, así como con Dart y Flutter. También soy autor e instructor de varios cursos y tutoriales, así como autor de algunos libros en Internet, especialmente sobre PWA. En mi tiempo libre, también organizo muchos encuentros y conferencias. Esta es mi pasión. Pueden encontrarme en Internet con este identificador casi en todas partes.

Volviendo a nuestro hilo principal. Cuando hablamos de nuestro hilo principal, nos referimos a muchas cosas que suceden allí. Cuando se trata del hilo principal, imaginen esta imagen, muestra cómo funciona un hilo principal. Tiene bucles incluso. Descarga JavaScript, lo analiza, aplica estilos, realiza el diseño, pinta, repinta, compone y muchas cosas más. Entonces, si están pensando en el hilo principal, tiene muchas tareas en sus manos. Y al crear aplicaciones complejas, incluso agregamos más. De hecho, esperamos ofrecer 60 FPS, 60 cuadros por segundo. Eso hace que sea aún más difícil para el hilo principal asumir toda esta responsabilidad.

Permítanme contarles un presupuesto rápido. Si queremos enviar 60 cuadros en un segundo, tenemos un presupuesto de aproximadamente 16.6 milisegundos, ¿verdad? Hablemos de este presupuesto en diferentes formas. Si hablamos de un teléfono muy bueno con un hardware de alta especificación en comparación con un teléfono de baja especificación, verán que este presupuesto en un teléfono está bastante bien, en otro teléfono, tal vez esté al límite y en otro teléfono, simplemente supera nuestro presupuesto. Ese es el momento en que nuestros usuarios ven cuadros entrecortados. Y eso ni siquiera es todo. Si hablamos de 60 FPS en diferentes tasas de pantalla, como 120 Hz, es aún peor. En 90 Hz, incluso tienes menos de 60, alrededor de 11 milisegundos, y en 120, incluso tienes menos. Eso trae esta imprevisibilidad a nuestra aplicación cuando la estamos entregando. De hecho, no sabemos si esta aplicación en este momento, si la están ejecutando en diferentes dispositivos, se ejecutará tan suave como lo que estamos probando en el iPhone o tal vez en una computadora de escritorio potente. Aquí es donde tengo que decir que esta es nuestra responsabilidad. Es responsabilidad de los desarrolladores manejar todas estas situaciones inesperadas y reducir la mala experiencia del usuario al liberar algunas tareas del hilo principal a otros hilos. Y de hecho, tenemos un viejo amigo.

Alrededor de 2017 o 2012, casi todos los navegadores tienen un buen soporte para eso. Web Worker es una herramienta o API muy subutilizada en el navegador. Pero hablemos de eso. Entonces, rápidamente, hablando de Web Worker, es similar a un navegador sin interfaz, ¿verdad? Simplemente ejecuta todo de forma aislada. No hay variables que podamos compartir y realmente puedes ejecutar tareas, incluso ejecutarlas en paralelo. Y, ya sabes, la única cosa es que esto es sin interfaz porque no tiene acceso al DOM. Y, ya sabes, esa es una de las características de este navegador, ¿verdad?

Entonces, si hablamos rápidamente, Web Worker es eso, ¿vale? La forma en que funciona es que simplemente creas una nueva instancia de Web Worker y luego te comunicas con ella a través de un sistema de mensajería. Web Worker tiene exactamente las mismas características que el hilo principal. Tiene una cola de mensajes y todas las cosas que tienes. Incluso puedes ejecutar WebAssembly y cosas así. Pero entonces, si eso es fácil, ¿por qué no lo usamos? Porque, ya sabes, este sistema de mensajería puede no ser como la forma en que realmente nos gusta trabajar en el trabajo diario, ¿sabes? Estamos muy acostumbrados a la sincronización y las promesas, ya sabes, o a veces los callbacks. Digamos que en estos días, basado en promesas, ya sabes, una forma de trabajar, una forma de codificar. Y sería muy agradable, en lugar de este sistema de mensajería, poder acceder rápidamente a un hilo de trabajo y luego obtener una respuesta después, ¿verdad?

Aquí es donde entra en juego esta biblioteca comblin. Con esta biblioteca, la forma en que realmente creamos Web Workers es bastante fácil. Simplemente creamos nuestro trabajador y luego lo envolvemos con comblink y luego obtenemos acceso al servicio o las funciones que estamos exponiendo desde el trabajador. Y lo bueno es que, como se ve en el ejemplo de código, comblink lo convierte en una promesa. Promisifica todas las funciones y simplemente puedes esperar el resultado y luego hacer algo con eso. Entonces, en un archivo JavaScript de trabajador, también necesitas exponer lo que quieres realmente exponer al hilo principal aquí. Y simplemente le dices a comblink, oye, estas son mis funciones o este es mi objeto, que quiero exponer. De hecho, si quiero dar un ejemplo en React, digamos, cuando estamos creando un trabajador aquí, que es rápido y luego lo asignamos a una variable, y aquí es donde tenemos nuestra función en un trabajador donde tenemos una tarea de cálculo intensivo, como quiero ordenar, digamos, un array. Entonces aquí simplemente puedo enviar este array al trabajador y hacer algo y obtener el resultado de vuelta y configurarlo. Y si terminé con eso, también puedo terminar mi trabajo. Y déjame decirte esto ahora mismo. ¡Esto es increíble, ¿verdad? Lo que podemos hacer ahora es diferenciar entre nuestra lógica de negocio, digamos, podemos realmente mantener nuestra lógica de negocio en nuestro hilo de trabajo de alguna manera, y podemos tener nuestra lógica de interfaz de usuario en el hilo principal. Y esto es en realidad cómo los desarrolladores móviles, como en Suite o Android, suelen trabajar. Tienes un hilo de interfaz de usuario donde tienes acceso a la interfaz de usuario y puedes manipularla. Y en un hilo principal, tal vez en un navegador, podemos de alguna manera simular eso. Podemos decir, oye, este es el hilo principal. Solo tengo acceso al DOM y quiero manipularlo, ¿verdad? Y luego hay alguna lógica que puedo mantener en otros hilos y hacer algo con eso y luego obtener el resultado.

Entonces, si estás utilizando un nuevo hilo de trabajo, en realidad estás agregando un poco de sobrecarga aquí para la instanciación, apertura, sistema de mensajería posterior, y cosas así. De hecho, es posible que no sea más rápido. Lo siento. Pero puedo decir que es más confiable. Como viste en el ejemplo, no bloqueas tu interfaz de usuario. Simplemente envías estos mensajes, esta lógica de negocio a un hilo de trabajo y obtienes la respuesta de vuelta en tu hilo principal. Y eso lo hace más confiable y menos sensible. Y, bueno, podría ser incluso más rápido. Sí, puedo decir eso. Si tu teléfono, o digamos en el navegador, en el escritorio, tienes varios núcleos. Sí, podría ser el caso de que se ejecuten en paralelo. Tengo otra charla sobre paralelismo en JavaScript. Así que puedes ver eso más tarde. Entonces se ejecuta en un núcleo diferente al mismo tiempo. Y podría ser incluso más rápido. Pero como desarrollador web, no lo sabes con certeza. Y también podría ser un poco arriesgado en ese caso.

Entonces pasemos al siguiente ejemplo aquí. Otro ejemplo aquí, verás que quiero ordenar una lista pesada aquí con Worker. Y sin Web Worker, verás que estoy bloqueando mi animación de interfaz de usuario aquí en este caso. Y es muy impredecible. Y mi interfaz de usuario y mi usuario no estarán contentos con eso.

Otro amigo nuestro en estos días en el navegador con un muy buen soporte en la mayoría de los navegadores es WebAssembly. Pero cuando se trata de WebAssembly, rápidamente pensamos en lenguajes como C, C++, Rust, ya sabes, este tipo de lenguajes. No voy a hablar sobre la teoría detrás de esto porque probablemente hayas oído hablar de WebAssembly y conozcas la idea detrás de ello. Pero cuando se trata de un desarrollador de JavaScript, tengo que decir que, bueno, es divertido aprender otro lenguaje, pero a veces quizás no tenemos tiempo para un proyecto. Tal vez estamos apurados para hacer algo y es un poco arriesgado ir con otro lenguaje que no conocemos, ¿verdad? Entonces es cuando entra en juego AssemblyScript. AssemblyScript es en realidad un compilador con un subconjunto estricto de tipo de script. Así que se compila a WebAssembly. Y lo bueno de esto es que escribes tu tipo de script de la misma manera y probablemente como desarrollador de JavaScript, ya estás familiarizado con ese lenguaje. ¿Sabes cómo escribir este código? Incluso si no lo sabes, escribir código de tipo de script es mucho más fácil para nosotros como desarrolladores de JavaScript, ya sabes, en comparación con C o C++.

Y sorprendentemente, es bastante fácil configurar un script de ensamblaje en tu proyecto o ejecutar o crear un proyecto con ensamblaje. Simplemente ejecuta unos comandos simples y verás en las diapositivas, y luego obtendrás todo ya estructurado para ti. Y aquí lo tienes, tienes tu archivo de tipo de script, como ves, el archivo de entrada principal, simplemente puedes seguir adelante y escribir tu función, crear un array, aleatorizarlo o ordenarlo. Estos son los ejemplos que acabo de escribir aquí, o Fibonacci en este ejemplo sin optimization. Y puedes exportarlos como lo haces en TypeScript, con un tipo especial, ya sabes, tipos especiales en TypeScript aquí, que en realidad son tipos de ensamblaje. Y simplemente puedes seguir adelante y leer sobre estos tipos y familiarizarte con ellos. También hay algunos componentes integrados y modules para esto y bibliotecas para scripts de ensamblaje que puedes leer al respecto.

Una vez que hayas terminado, sorprendentemente, nuevamente, eso lo hace muy fácil para nosotros, simplemente ejecuta un comando simple npm run as build, y luego obtendrás tu archivo Wasm listo para usar. Y la parte más importante es cuando quieres instanciar este script de ensamblaje, porque la forma en que funciona es bastante simple. Cuando importas el cargador de assembly script, simplemente puedes obtener tu archivo Wasm, y aquí lo tienes, boom, todo está hecho. Si has terminado, o si vas a leer sobre WebAssembly, sabes que la instanciación de un archivo Wasm es un poco de trabajo. No es solo una línea de código, son unas cuantas líneas de código. Entonces, un script de ensamblaje lo hace muy fácil para ti instanciar tu archivo Wasm en este caso, y luego simplemente es una función basada en promesas, por lo que simplemente puedes esperar eso y obtener el resultado y hacer algo con tu aplicación. En este caso, estoy estableciendo un estado. Así que veamos un ejemplo aquí, una función que proviene de WebAssembly y una función similar en la parte de JavaScript. Como ves aquí, la versión de ensamblaje no bloquea, nuevamente, y simplemente llega muy rápido.

Si observas el registro de la consola, verás que la primera vez que ejecuto la función de la versión de WebAssembly, es bastante rápida. Es casi siete veces más rápida, pero cuando realmente ejecuto la parte de JavaScript, la primera vez es más lenta. Pero siempre mide, porque lo que puedo decir es que lo que ejecutas en WebAssembly se mantendrá en el mismo camino, y siempre será fluido y predecible en términos de rendimiento, mientras que JavaScript no es así. Así que siempre mide y observa la diferencia.

Y pasemos al ejemplo final, que es tu tarea, debes hacerla. En primer lugar, puedes acceder a estos ejemplos fácilmente. Y, en segundo lugar, aquí está la tarea. Así que, abres esto, ves esta pantalla aquí, ejecutas y esto transcodifica tu cámara en vivo a un formato MP4, e incluso puedes descargarlo sin bloqueos, y se ejecuta en un hilo de WebAssembly. Así que no voy a ejecutar esto porque la transcodificación aquí lleva un poco de tiempo, así que te dejo que lo intentes y veas cómo funciona.

Y dicho esto, digamos que- aprovechemos el poder de los workers, utilicémoslos, hagamos una aplicación más confiable y predecible e incluso utilizable para nuestros usuarios utilizando y aprovechando estas APIs en nuestro navegador y utilizando algunas de las bibliotecas que facilitan aún más su uso, ¿verdad? Y antes de pasar a la última diapositiva, Feliz cumpleaños React Summit. Este es mi regalo. Estas son mis diapositivas para ti. Espero que tengamos una tarta muy esponjosa para tu cumpleaños. Y pasemos a la última diapositiva. Gracias por escucharme. Puedes acceder a estas diapositivas y al enlace al código fuente a través de este enlace corto, Y si tienes alguna pregunta, puedes contactarme en Twitter. Soy bastante activo allí. O envíame un correo electrónico. Estaré encantado de responder todas tus preguntas. Gracias.

Adit, ¿cómo estás hoy? Estoy muy bien, de hecho. Muy bien. Estoy muy emocionado de unirme a ti. Muy emocionado hoy. Es una conferencia increíble. Tu entusiasmo por, ya sabes, estar fuera del hilo es simplemente incomprensible, supongo, en este momento. Pero realmente me gusta eso. Y tengo preguntas. Y creo que hay muchas cosas que mencionaste que son realmente, realmente importantes y relevantes. Porque estabas analizando los teléfonos móviles y lo que está sucediendo con el estado de los móviles en general.

Es muy interesante porque hubo un artículo hace solo un par de días diciendo que, sabes, los teléfonos antiguos que descartamos porque ni siquiera nos gustan y hay nuevos que están saliendo, simplemente no desaparecen. Terminan pasando por tres generaciones. Así que terminas, tal vez, sabes, segunda generación, tercera generación, todavía se están utilizando. Y si estás usando una aplicación pesada hoy en día, esto será simplemente una experiencia horrible.

Así que tal vez para desglosarlo realmente en partes estratégicas. Entonces, si tienes una aplicación antigua y quieres que sea rápida y te das cuenta de que tienes algunos problemas con el hilo, ¿cómo decides qué debe ir en WebWorker, qué debe ir en Worklet, qué debe ir en WebAssembly? ¿Cuál es tu estrategia? Sí, esta es una pregunta muy, muy buena. A menudo me hacen esta pregunta. Es un poco amplia para responder, sin embargo, pero trato de simplificarla un poco y responderla. Entonces, lo que suelo hacer, solo doy mi experiencia personal, es que, como dijiste, trato de ejecutar mi aplicación primero en un dispositivo de muy bajo nivel y luego trato de averiguar qué parte de la aplicación necesita un poco de mejora, ¿verdad? Entonces, y dependiendo de esa mejora, decido si esto debería ir a WebWorker o si esto debería ir a Worklet, por ejemplo, utilizando Worklet. Digamos, como ejemplo, di un ejemplo sobre Redux, ¿verdad? A veces sucede, sabes, tienes una operación síncrona en tu aplicación y ves que simplemente estás ejecutando algún código de JavaScript y es solo una ejecución. Y luego sientes, bueno, esto está bloqueando mi bucle de eventos por un tiempo. Entonces, y luego está bloqueando mi interfaz de usuario, ¿verdad? Entonces, probablemente este sea un buen candidato para moverlo allí. Pero luego vas a otra parte de tu aplicación y ves que, oh, esto es como un fondo que renderizo, ya sabes, y bueno, el renderizado causa un poco de tartamudeo cuando se ejecuta la animación, ¿verdad? Entonces pienso, oh, entonces tenemos otra API, worklet para renderizar este formato de bajo nivel de renderizado como gráficos y audios, ¿verdad? Entonces decido mover eso a worklet en lugar de hacerlo en WebWorker. O a veces sientes que, bueno, definitivamente puedes usar, de hecho tuve un ejemplo en la charla. Entonces definitivamente puedes usar algunas bibliotecas de JavaScript, por ejemplo, y decodificar o codificar o comprimir algunos datos o imágenes o videos y cosas así, ya sabes, en tu aplicación, seguro. Pero luego esa es probablemente la parte en la que piensas que, oh, esta parte, probablemente hay mejores bibliotecas en C o tal vez algunas bibliotecas se han escrito en ROS, y luego puedo compilarlo a WebAssembly. Así que esto es muy importante, de hecho. Cuando hablamos de estas API, es muy, muy importante hablar sobre qué parte de la aplicación tienes un problema. Entonces, y luego necesitas averiguar en función de eso, cuál está más cerca de la API que necesitas usar, ¿sabes? Pero generalmente lo hago de esta manera.

Sí, definitivamente tiene sentido, y es realmente interesante que tengamos todas estas opciones disponibles, ¿verdad?, y así podemos aprovecharlas. Y probablemente, sabes, cada aplicación sofisticada probablemente usará una combinación muy interesante, una combinación híbrida de todas esas cosas.

También hubo muchas preguntas en el chat. Una de ellas fue de Jay Holfeld, supongo. Y Jay quiere saber, ¿cuál es el compromiso al crear un Web Worker y hacer el trabajo? ¿Vale la pena usar Web Workers incluso para tareas mínimas? Sí, en primer lugar, hola, Jay. Muy buena pregunta. Si prestas atención a una de mis diapositivas, dije que hay un poco de sobrecarga cuando realmente estás creando un Web Worker. Técnicamente, estás agregando un poco de trabajo a tu aplicación o carga de trabajo, digamos. Así que hay un compromiso, seguro. Pero entonces, ¿tienes que usar Web Worker para todo? Bien, hoy aprendí que hay una biblioteca que simplemente puedo usar y luego está sincronizada. Como la forma en que escribo mi JavaScript.

Pero es muy fácil, bueno, a partir de mañana puedo simplemente enviar todo a Web Worker. Bueno, eso no es cierto. Así que tenía otra diapositiva, y enfaticé que necesitas medir cuando estás enviando algo a un Worker. Necesitas ver si esta ejecución va a Web Worker, si vale la pena en términos de experiencia del usuario. Por ejemplo, si solo estoy moviendo esto a un Web Worker y no resuelve ningún problema en términos de experiencia del usuario. No había bloqueos, no había cosas que necesitaban mejorar, entonces tal vez no deberías hacerlo, porque hay un compromiso. Estás agregando un poco de carga de trabajo. Y también recuerda, estás consumiendo más recursos de tu usuario, ya sabes, el hardware del usuario, por así decirlo. Así que esto es algo a lo que debes prestar atención.

Entonces, tarea pequeña o tarea grande, eso es una cosa. Otra cosa es que debes cuidar la experiencia del usuario y ver dónde en tu aplicación algo está bloqueando. De acuerdo. Una pregunta muy similar y ligeramente relacionada viene de Tushar, quien preguntó, ¿cuántos hilos tipo worker.js podemos crear sin afectar demasiado el rendimiento general? Puedo verme escribiendo muchas cosas usando comlink en muchos, muchos, muchos archivos. Sí, sí. Bueno, muy buena pregunta de nuevo. Técnicamente, puedes crear un número ilimitado de web workers. Entonces no hay límite. Siempre y cuando los recursos del sistema del usuario sean bajos o no estén completamente consumidos o el navegador no mate tus web workers. Pero, ¿deberías hacerlo? Bueno, tal vez no. Necesitas decidir cuándo usarlo. Y lo más importante, cuando estás usando algo, digamos en una página debido a algún problema, necesitas usar web worker y comlinks ayudan, ¿verdad? Entonces, después de abandonar esa página o hacer esa tarea y está terminada y ya no la necesitas, simplemente terminas tu worker, simplemente limpias después de ti mismo. Y esa es una regla general en la programación, ¿verdad? Así que limpiemos cuando no necesitemos nada, ¿de acuerdo? Así que cuando terminemos una tarea, la respuesta corta es, por supuesto, puedes crear un número ilimitado de workers, pero ¿deberías hacerlo? Tal vez no, porque no quieres realmente saturar los recursos de tus usuarios y hacer que se bloquee la pestaña o el navegador que está usando el usuario porque has abierto demasiadas cosas y no es necesario. Solo necesitas hacerlo cuando sea necesario y debes limpiar después para asegurarte de que no haya fugas de cosas o que no haya, digamos, algo que esté agotando los recursos del sistema de tus usuarios.

Respuesta muy detallada. Gracias, Majid. Otra pregunta acaba de llegar de Alexander Botterham. Ya usamos web workers para el análisis de texto en tiempo real. Si queremos aumentar el rendimiento utilizando WebAssembly, ¿cuál sería la mejor manera de convertir esta base de código existente, que es realmente enorme, a WebAssembly poco a poco?

Sí. Muy bien. Sabes que hoy introduje AssemblyScript. Y el primer paso, tal vez, es que puedes, si está en JavaScript que escribiste, simplemente escribirlo ahora mismo en TypeScript, si no lo has escrito. Ese es probablemente el primer paso. Y el segundo paso es, pieza por pieza de este código TypeScript, simplemente averiguar qué parte puedes usar, o puedes escribir con AssemblyScript, el conjunto específico de tipos de ensamblaje, y luego convertirlo probablemente a AssemblyScript. Pero también debes pensar si vale la pena. Porque como dije en las diapositivas, estás usando WebAssembly porque WebAssembly, cuando se ejecuta, es confiable, ¿verdad? Desde el principio hasta el final, pero cuando usas JavaScript, puede que no sea tan confiable. Puede depender del motor cuando optimiza el código JavaScript en el navegador. Puede ser muy eficiente o poco eficiente. Por lo tanto, es importante medir cuando quieres hacer eso, en primer lugar. Técnicamente, probablemente puedas tomar una pequeña parte de eso, hacer un experimento, ejecutarlo con Assembly Script, compilarlo y ver si vale la pena en términos de medidas de rendimiento. Tiene sentido.

Hablando de eso y hablando de WebAssembly, una cosa que también me preguntaba, si usas WebAssembly para una aplicación grande porque es bueno para cálculos pesados, ¿cómo lidias con la carga de esa gran aplicación que se sirve a través de Internet? ¿Es una forma incremental de hacerlo? ¿Qué sugieres hacer allí? En realidad, muy buena pregunta que hiciste. Al igual que otros patrones en la web, hay una forma perezosa de cargar WebAssembly. Técnicamente, debes averiguar qué parte es la más importante al principio, puedes cargar eso y una vez que necesites más cosas, como un complemento o paquete o algo, simplemente modularizas tu ensamblaje y los cargas de forma perezosa después. Este es un patrón que ya existía para cargar scripts de WebAssembly. Y hay buenos ejemplos en Internet que se han creado de esta manera. Por lo tanto, no necesitas cargar, como, 10 megabits o 10 megabytes de ensamblaje justo al principio de la aplicación. Tal vez necesites un megabyte o menos que eso antes de la compresión. Por lo tanto, es importante pensar en asegurarse de que estás cargando lo necesario al principio y luego continuar cargando lo necesario después.

De acuerdo, excelente. Gracias por la maravillosa pregunta. Fue muy, muy perspicaz. Queridos amigos, se nos acaba el tiempo aquí, así que por favor den una cálida ronda de emojis de sol a nuestro maravilloso invitado, Majid. Y por favor únanse a él en la sala más tarde para hacer preguntas directamente. Muchas gracias por acompañarnos, Majid. Gracias.