Cómo funcionan los módulos de JS: una perspectiva del navegador

Rate this content
Bookmark

Los módulos son una herramienta popular para los desarrolladores de JavaScript. Recientemente, ha habido varias propuestas que abordan cómo funcionan los módulos, incluyendo Import Maps, Top level await, JSON modules, Module asserts y muchos otros. Pero, ¿cómo funciona el sistema de carga de módulos y cómo estas propuestas lo mejoran? ¿Cómo se ve desde la perspectiva del navegador cargar un árbol de módulos con un mapa de importación? Exploraremos estas preguntas y más, brindándote una mirada detrás de escena a la carga de módulos en JS.

26 min
16 Jun, 2022

Video Summary and Transcription

Esta charla discute los módulos de JavaScript desde la perspectiva de un navegador, explorando cómo funcionan y sus diferencias con el JS común. Cubre temas como la carga de módulos, los registros de módulos y el mapa de módulos. Se explica el proceso de carga y evaluación de los módulos, junto con los desafíos de la adopción de módulos y el rendimiento. La charla también aborda la carga perezosa, la importación dinámica y la reflexión de importación. El orador comparte una anécdota humorística durante la sesión de preguntas y respuestas sobre robar una camiseta al equipo de DOM.

Available in English

1. Introducción a los módulos de JavaScript

Short description:

Vamos a hablar de los módulos de JavaScript, específicamente desde la perspectiva de un navegador. Soy Yulia Starzev, una ingeniera de software de Mozilla, trabajando en SpiderMonkey. Me encontré con un interesante tweet de mi ex colega, Jason Orndorff, sobre una invariante de los lenguajes de programación. Vamos a utilizar el tema de los peces y compartir un chiste de David Foster Wallace sobre dos peces en el océano.

Esa es una introducción muy interesante. Por cierto, si alguien está pensando, oh, ¿qué pregunta debería hacer en la sesión de preguntas y respuestas, pregúntame cómo conseguimos el nombre SpiderMonkey. Es una historia divertida.

Hola a todos. Vamos a hablar de los módulos de JavaScript. En particular, vamos a tomar una perspectiva un poco inusual, que es la de un navegador. Así que mi nombre es, eso fue rápido. Mi nombre es Yulia Starzev. Soy una ingeniera de software de Mozilla. En particular, trabajo en SpiderMonkey, que es el compilador de JavaScript para Firefox. De hecho, no solo hacemos JavaScript, también hacemos WebAssembly. La parte en la que trabajo es la del lado de JavaScript. También trabajo un poco en el DOM. Y mi enfoque es el diseño e implementación de características de JavaScript.

Para comenzar esta charla, cuando la estaba escribiendo, estaba un poco atascada y pensé, no sé cómo voy a unir todo esto y hacerlo entretenido. Esto es un tema un poco aburrido. Y me encontré con este genial tweet de mi ex colega, Jason Orndorff. Solía trabajar en SpiderMonkey conmigo y aprendí mucho de él. Especialmente sobre el diseño de lenguajes y los lenguajes en sí. Él escribió esta genial... Llamémoslo una invariante de todos los lenguajes de programación que implementan un método de reversión de cadenas. Por cierto, JavaScript no implementa el método de reversión de cadenas. Pero efectivamente, string.reverse en cualquier lenguaje en el que lo intentes no revertirá una imagen de un pez.

Aquí tenemos un ejemplo de un programa en Ruby en el que tenemos dos versiones de una imagen de pez, una hecha con corchetes angulares y la otra hecha como un emoji. Y notarás que cuando ejecutamos este código, efectivamente, el pez sigue mirando en la misma dirección. Podemos decir que este pez es invariante, una palabra importante que usaremos. Así que el pez es nuestro tema, y como tengo el tema de los peces, puedo usar uno de mis chistes de apertura favoritos de una presentación principal que viene de David Foster Wallace en su presentación de 2005 en una universidad, que va más o menos así. Dos peces están nadando en el océano y simplemente ocupándose de sus asuntos. Son jóvenes. Son nuevos en este hermoso mundo azul, y un pez mayor pasa por allí y nada junto y dice, ¿cómo está el agua, chicos? Es solo un saludo, y este pez mayor se va nadando.

2. Introducción a los módulos de JavaScript (continuación)

Short description:

El sistema de módulos es similar a algo que damos por sentado. Los módulos ES6 se introdujeron en 2015. Vamos a explorar cómo funcionan los módulos, sus diferencias con el JS común y cómo el sistema de módulos construye un gráfico. El registro del módulo actúa como un plano para nuestro módulo.

Un rato después, los dos peces siguen nadando en silencio cuando uno de ellos se voltea hacia el otro y dice, ¿qué demonios es el agua? Este es un gran chiste para establecer el escenario de algo que podríamos dar por sentado, algo que existe en el éter y parece estar ahí, algo que no necesitas cuestionar.

Es un poco como lo que es el sistema de módulos. Imagino que en los últimos siete años de existencia de los módulos ES6, muchos de ustedes lo han adoptado y lo utilizan como su forma principal de escribir módulos de JavaScript, especialmente la sintaxis de importación-exportación. ¡Oh, sí, olvidé corregir eso! Por alguna razón, ¡lo tengo dos veces! ¿Cómo llegamos aquí?

Una pregunta que podrían hacer es, bueno, ¿cuándo comenzaron los módulos? ¿Cuánto tiempo tiene este problema? Tengo algo de respuesta aquí para ustedes. No puedo darles una respuesta definitiva, pero aquí hay una base de código que es una parte del código en la base de código de Mozilla. Se llama el cargador de componentes MOZ.js. Quiero destacar la fecha aquí, que es 1999. Esta base de código tiene un lugar especial en mi corazón porque resulta que estoy trabajando en ella hoy. No todos los días puedes decir que el código que estás escribiendo está listo para obtener su maestría.

Para muchos de ustedes en la audiencia, es probable que los módulos realmente hayan cobrado importancia con la introducción de Node. En particular, esta publicación de blog de 2009 de Kevin Dengar es un punto importante, porque aquí está preguntando, también es un antiguo empleado de Mozilla, está preguntando, ¿qué necesita el JavaScript del lado del servidor? En esta publicación de blog, introduce la necesidad de un sistema de módulos e introduce un nuevo grupo de la comunidad llamado grupo de la comunidad de JavaScript del servidor. Este grupo luego cambió su nombre a CommonJS, que imagino que suena bastante familiar. Como se mencionó, seis años después, en 2015, finalmente se introdujeron los módulos ES6 en la especificación. Los navegadores tardaron un poco más en implementarlo. Llegaron en 2018. Introdujo varias características en el navegador, incluida la sintaxis de importación-exportación con la que muchos de ustedes están familiarizados.

Entremos en el meollo de esta charla. ¿Cómo funcionan los módulos? ¿Qué es este sistema de módulos? ¿Qué hace? ¿En qué se diferencia del JS común? ¿Por qué no especificamos CommonJS? Eventualmente, veremos cómo se ve la función para el sistema de módulos en los navegadores. Una cosa para empezar es que el sistema de módulos construye un gráfico. Este gráfico permite ciclos. Si tienes un módulo que importa a algún vecino, y ese vecino importa a un ancestro de tu módulo inicial, esto funcionará. Es una característica importante para la ergonomía del desarrollador. No siempre quieres romper los ciclos manualmente. El navegador lo hace por ti. Entonces, ¿cómo construimos realmente este gráfico? ¿Cómo funciona? ¿Cómo nos aseguramos de que realmente puedas escribir tus módulos de esta manera cíclica? Voy a empezar desde la perspectiva de un nodo. El nodo, en este caso, en este gráfico, será un solo script de módulo. En la especificación, tenemos una estructura de datos llamada registro del módulo, y el registro del módulo es este nodo. Es un poco como un plano para nuestro pez, para nuestro módulo que estamos escribiendo. Y viene en algún lugar en el medio del proceso que estamos a punto de describir. Si quieres echar un vistazo a la base de código, tengo el texto fuente de la implementación de Mozilla enlazado allí.

3. Carga de módulos ES6 y registros de módulos

Short description:

Un registro de módulo es una tabla con campos de importación y exportación. Define claves para importaciones y exportaciones, utilizando especificadores de URL para importaciones y apuntando a código en vivo para exportaciones. En el JS común, cargar un módulo es sincrónico y bloquea el hilo principal, lo que causa problemas de rendimiento. Los módulos ES6 se cargan de manera diferente, analizando todo el archivo y construyendo un registro de módulo. Este registro proporciona una vista localizada del gráfico de módulos, incluyendo importaciones y conexiones salientes.

Puedes echar un vistazo a las diapositivas más tarde. Efectivamente, ¿qué es un registro de módulo? Básicamente, es una tabla con un par de campos. Tienes un campo de importaciones y un campo de exportaciones, y el campo de importaciones define un número de claves que podrías llamar nombres de variables, al igual que las exportaciones, definen un número de claves, la diferencia es que las importaciones utilizan el especificador de URL para el hijo dado que queremos importar, y las exportaciones apuntan a un fragmento de código específico que estará en vivo.

Ahora, hablemos un poco sobre cómo podríamos cargar este módulo. ¿Cómo empezamos a construir esta estructura de datos? Antes de decirte cómo funciona esto en ES6, te diré cómo funciona en JS común, porque el contraste es importante, especialmente para discusiones posteriores. Digamos que este es, vamos a fingir que este es el caso típico para JS común. Escribes un fragmento de código y tienes un bloque de JavaScript que está haciendo algún tipo de trabajo, luego encuentras una declaración require. En este caso, el trabajo que estamos haciendo es crear una ruta dinámica, y luego requerimos esa ruta y la cargamos. El navegador ya ha realizado el paso de cargar este script, lo ha analizado y ahora lo está ejecutando, por lo que pausa la ejecución y continúa con otra carga, otro análisis, otra ejecución. En nuestro otro módulo, comenzamos a ejecutar y luego encontramos otra declaración require, así que nos vamos al éter de Internet para cargar ese nuevo módulo, luego continuamos nuestra ejecución y finalmente volvemos a nuestro módulo anterior y continuamos ejecutando.

Entonces, ¿cuál es el problema con este diseño? ¿Por qué no lo implementamos? El problema es que notarás que no hay ninguna sintaxis de promesa aquí en ninguna parte, y por supuesto, el common.js fue antes del await de nivel superior. Un problema aquí es que esto es completamente sincrónico, y un problema con esto es que en la plataforma web no podemos bloquear el hilo principal para una solicitud de red. Para system.js y common.js, esto estaba bien. Te daré una estimación aproximada en términos de tiempo aquí. Digamos que tienes un procesador, tienes el registro en el procesador para acceder a ese registro, lleva como un segundo acceder a la memoria principal, estás mirando alrededor de seis segundos o algo así. Si quieres obtener la memoria principal, que es la RAM, si quieres obtener algo de la red en esta escala de tiempo, estás mirando alrededor de cuatro años. Esto es una parte muy significativa del tiempo que pasarás en la red. Además, hay una invariante importante de la plataforma web, se llama ejecución hasta la finalización. ¿Qué significa ejecución hasta la finalización? Si has estudiado sistemas operativos, es posible que estés familiarizado. Pero si no lo has hecho, ejecución hasta la finalización significa que una tarea dada seguirá ejecutándose hasta que voluntariamente ceda el control del procesador o termine su tarea. Eso significa que no podemos interrumpir una tarea que, por ejemplo, está bloqueando el hilo principal, por lo que seguirá bloqueado. No es una gran experiencia para los usuarios de la web, y eso hace que sea una API muy propensa a errores para que los desarrolladores la usen. Por lo tanto, no pudimos introducir la carga sincrónica.

Entonces, ¿cómo resolvemos este problema? Bueno, esto nos lleva a la pregunta de cómo cargamos un módulo ES6. Se ve un poco así. Recuerda que dije que en JS común se carga, analiza y evalúa el módulo todo en un solo paso. En ES6, lo hacemos de manera diferente. Primero analizamos todo el archivo y luego construimos este registro de módulo que mencioné antes. El registro de módulo nos da esta imagen de una vista localizada en el gráfico, así que soy yo, estos son mis vecinos, estas son mis conexiones entrantes, estas son mis conexiones salientes. Una vez que tenemos esto, también tenemos las importaciones, las otras URL que necesitamos cargar, así que podemos seguir adelante y cargar otro script. A medida que cargamos ese otro script, podemos hacer el mismo proceso aquí, que es primero analizar y luego construir ese registro de módulo.

4. Carga de módulos y el mapa de módulos

Short description:

El bucle de análisis-descarga es una parte importante de cómo el sistema de módulos difiere de common.js. El mapa de módulos, una estructura de datos global, nos ayuda a romper los ciclos al cargar módulos. Se utilizan URL para determinar la ubicación de los módulos y descargar los archivos necesarios.

Notarás que no hacemos ninguna evaluación en esta fase. Esto se llama el bucle de análisis-descarga. Es una pieza importante de cómo el sistema de módulos difiere de common.js.

Una pregunta importante que te estarás haciendo es ¿cómo implementas ese comportamiento de bucle de modules? ¿Cómo rompes los ciclos y te aseguras de no entrar en un bucle infinito de modules que se importan continuamente entre sí? La respuesta a eso se encuentra en una estructura de datos global que representa nuestro gráfico. Eso se llama el mapa de módulos. Puedes encontrarlo en la especificación si quieres, y rápidamente explicaré cómo el mapa de módulos nos ayuda a romper los ciclos cuando estamos cargando modules.

Una nota importante que voy a hacer aquí, verás que el origen de estas URL está en rojo. Es importante tener en cuenta que tenemos que trabajar con URL y son URL completamente resueltas que podrías escribir en tu navegador y resolver a una página web real. Pero debido al espacio en las diapositivas, esto va a desaparecer, así que en tu mente, si ves una URL relativa, siempre reemplázala por una URL completamente resuelta. Pero empecemos con cómo el mapa de módulos resuelve los ciclos en el gráfico. Comenzamos en un estado llamado no vinculado. No hemos establecido relaciones entre vecinos en el gráfico, y main.js es nuestra ruta, path.js es el hijo inmediato, y otro módulo que es el hijo inmediato de path.js.

Main.js comienza su proceso de vinculación, voy a ver a mis hijos. Ve que tiene un hijo y comienza a hacer lo mismo. Path dice que tiene hijos, voy a comenzar a vincular. Otro módulo es el siguiente en el algoritmo y dice que es mi turno de comenzar a vincular. Pero no tengo hijos, así que ahora estoy automáticamente vinculado. Ese es mi estado predeterminado. Debido a que otro módulo se ha vinculado, path.js dice que todos mis hijos ahora están vinculados, eso significa que yo también estoy vinculado. Main.js dice que todos mis hijos están vinculados, por lo tanto, yo también estoy vinculado. Luego traemos el ciclo, que es importar path.js. Va a ver path.js. Aquí es donde se rompe el ciclo. Debido a que path.js ya está vinculado, terminamos el algoritmo allí, y el import de path.js dice que también está vinculado. En la base de código de Firefox, la forma en que representamos nuestro mapa de módulos es con dos tablas hash. Una de ellas es la tabla hash de descarga y la otra es la tabla hash de descarga. Lo que nos dice qué estamos cargando actualmente y qué hemos cargado. Nos evita volver a cargar cosas de la red. Los enlaces están todos ahí. La siguiente pregunta es ¿por qué estamos usando URL? La razón por la que estamos usando URL es que tenemos que saber dónde buscar, y antes de una cierta propuesta de la que hablaremos en un segundo, no había forma de determinar qué la ubicación y sin la ubicación no podemos descargar el archivo y no tenemos la información que necesitamos para aplicar CSP, que es la política de seguridad de contenido.

5. Proceso de carga y evaluación de módulos

Short description:

Gekko obtiene un script transformando bytes en un modelo de objeto de documento. SpiderMonkey analiza y construye el registro del módulo. La instanciación crea una instancia de módulo con código y estado. ES6 utiliza enlaces en vivo, a diferencia de common JS que hace copias del código. Gekko ejecuta el gráfico de módulos, comenzando desde el último hijo y luego la raíz.

Ambos muy importantes. Muy rápidamente, de principio a fin, todo el proceso de carga de módulos seguido del proceso de evaluación. Gekko obtiene un flujo de bytes de Internet que transforma en un modelo de objeto de documento, y luego dice, oh, tengo un script, necesito obtener eso. La obtención pasa por otro componente llamado Neko. Se encarga de descargar cosas de Internet, y una vez que Neko regresa a Gekko, la obtención pasa los bytes compilados y convertidos en bytes UTF-8 a SpiderMonkey. SpiderMonkey sabe cómo analizar, sabe cómo instanciar, sabe cómo evaluar. Gekko sabe con quién hablar. Esas son las relaciones entre esos dos componentes. SpiderMonkey recibe este archivo, ve, oh, sí, genial, puedo analizar esto, lo analiza, construye el registro del módulo, dice, hey, en realidad, necesito path.js, hey, obtención, ¿puedes obtener eso para mí, Gekko dice, claro, puedo obtener eso para ti. Aquí está el contenido de ese archivo. SpiderMonkey continúa y lo analiza. Genial, acabamos de terminar el bucle que hemos discutido hasta este punto. Ahora, el siguiente paso aquí es ¿cómo instanciamos este módulo? La instanciación significa tomar este registro del módulo y convertirlo en un código vivo y respirante. ¿Qué significa eso? Significa que una instancia de módulo es algo que tiene tanto código como estado en un solo lugar. Esto también difiere de common JS. Common JS haría copias de un determinado fragmento de código. Así que tendrías múltiples de ese estado y múltiples ejecuciones del código. En ES6, es todo un singleton. Tenemos algo llamado enlaces en vivo. Si este pez muere, será visible en todo el gráfico. Así que hemos pasado por todo el proceso de obtención. El proceso de ejecución se ve similar. Gekko informa a SpiderMonkey, hey, ¿puedes ejecutar ese gráfico de módulos que tienes? Gekko tiene acceso al módulo raíz de un determinado gráfico. Eso proviene de una etiqueta de script o una importación dinámica. Él dice, claro. Pero este módulo raíz tiene varios hijos. Voy a recorrer los hijos hasta el final y comenzar ejecutando el último hijo que tenga sentido, incluso si está en un ciclo. Tenemos una forma de determinar eso. Así que comenzaremos ejecutando ese hijo, y luego ejecutaremos la raíz. Y así es como funciona.

6. Adopción de módulos y rendimiento

Short description:

Cuando hablamos de ciclos, recorremos todo el árbol hacia abajo y establecemos el estado del último hijo posible. La adopción de módulos en la web es relativamente baja, con solo alrededor del 5-8% de la web en vivo utilizando módulos. La principal razón de esto es la velocidad de la red y las múltiples solicitudes de red requeridas por el sistema de módulos. Para abordar este problema, se ha escrito una propuesta llamada evaluación de módulos diferidos, que tiene como objetivo mejorar el rendimiento y la adopción de módulos.

Cuando hablamos de ciclos, por lo tanto, si tenemos esta situación, no voy a mostrar las diapositivas porque es exactamente lo mismo que el enlace, solo reemplaza no enlazado con enlazado, y la transición que estás haciendo es de evaluación a evaluado. Nuevamente estamos recorriendo todo el árbol hacia abajo y luego estableciendo el estado del último hijo posible y luego invirtiendo nuestra dirección. Muy bien.

Tenemos tres minutos. Veamos si puedo llegar al futuro. Entonces aquí está el gráfico de cómo se ve la adopción de módulos en la web y esto proviene de la telemetría de Google. Esto es exactamente cómo quieres que se vea un gráfico. Va hacia arriba y hacia la derecha. Esto es perfecto. Sin embargo, todos deberíamos ser críticos con los data y siempre verificar los ejes y notarás que hay un buen y viejo 8% allí, por lo que el 8% de la web en vivo está utilizando en realidad módulos. De hecho, esto es tal vez un poco más bajo, tal vez como el 5%, depende de qué parte de los data estés mirando. Así que eso es un poco bajo para algo que ha estado en producción durante los últimos ocho años más o menos, siete años. Es un poco bajo. Entonces la pregunta es por qué la gente no adopta la sintaxis de módulos. Tengo la sensación de que todos lo están usando como una herramienta de autoría en esta sala. Sin embargo, pocas personas lo están enviando a los navegadores.

Entonces tuvimos esta pregunta, ¿qué diablos es el agua? ¿De qué he estado hablando? Acabo de explicarte cómo funciona el sistema de módulos en los navegadores, pero en realidad no se está utilizando tanto, el sistema de módulos no está siendo utilizado por el código. Un problema es la velocidad de la red. Este es el problema que mencionamos antes cuando hablé de ejecución hasta la finalización. Ahora, Tobias hizo un gran trabajo hablando de Webpack y Webpack ha sido una solución porque puedes empaquetar todos esos archivos que necesitas usar y enviarlos directamente a los usuarios en lugar de hacer múltiples solicitudes de red, que es lo que requiere el sistema de módulos. Estamos haciendo múltiples solicitudes a la red y eso puede ser muy costoso. Además, hay una propuesta de herramientas llamada propuesta de paquetes web, no voy a entrar en detalles porque eso es realmente para herramientas, y si lo vemos desde una perspectiva de desarrollador, hay otras propuestas más interesantes potencialmente, espero, que puedo mostrarte. Podemos seguir hablando de este problema más amplio de rendimiento que es algo que pausa la adopción de módulos.

Recordemos que tenemos una invariante de ejecución hasta la finalización, lo que significa que no podemos detener el hilo principal y bloquearlo con una solicitud de red porque no tenemos forma de prelación, no tenemos forma de reordenar las tareas, deben ejecutarse hasta la finalización. La otra invariante que aún no he mencionado es el orden de ejecución. Lo que hace la sintaxis de módulos, si te has dado cuenta, porque vamos al último hijo y lo ejecutamos primero, significa que si lo has concatenado en un solo archivo grande, el comportamiento de un archivo concatenado es el mismo que el del módulo cargado. Entonces, esta es una propuesta que he escrito que actualmente está en la etapa uno, se llama evaluación de módulos diferidos que intenta abordar este problema. Tenemos, digamos, un archivo de JavaScript con una importación que ha sido este archivo de JavaScript que se ha escrito para la mejor legibilidad posible desde la perspectiva de un programador. Entonces tenemos una importación estática y luego tenemos varias funciones poco utilizadas que eventualmente utilizarán este código.

7. Carga perezosa e importación dinámica

Short description:

Para abordar el problema de la carga inmediata, se puede implementar un método de carga perezosa utilizando la importación dinámica. Sin embargo, este enfoque tiene un impacto significativo en la base de código, ya que convierte todo en async y await, alterando potencialmente la intención original del código.

Pero eso significa que no necesitamos cargar inmediatamente esta información de antemano. Todo esto sucede, tal vez un minuto después de la ejecución de la aplicación, en el cual podríamos hacer una carga intermedia. Entonces, ¿cómo solucionamos esto? Podrías escribir un método de carga perezosa que haga una importación dinámica del archivo en el que estabas originalmente interesado, pero esto tiene un impacto significativo en tu base de código. En particular, convierte todo en async y await, pero este async await es solo una capa de rendimiento en tu código, pero cambia semánticamente cómo funciona ese código. Lo que potencialmente confunde la intención original de lo que ese código estaba haciendo.

8. Evaluación de módulos y reflexión de importación

Short description:

La tercera evaluación de módulos introduce una nueva pieza en la declaración de importación, que es con lazy init. No es exactamente lo mismo que hacer una importación dinámica, pero te permitirá posponer parte de ese trabajo, para tener una aplicación más eficiente con algunas advertencias. He estado pensando en una sintaxis alternativa aquí, que es afirmar la pureza de un módulo. Existe una propuesta contraria llamada import reflection. Divide el cargador de módulos en piezas que tú como desarrollador puedes programar tú mismo. Por último, un problema interesante son los especificadores. Ahora existe una propuesta llamada import maps que te permitirá hacer eso. Además, import assertions y JSON modules.

La tercera evaluación de módulos introduce una nueva pieza en la declaración de importación, que es con lazy init. Esto te permite posponer la evaluación de ese módulo. No es exactamente lo mismo que hacer una importación dinámica, pero te permitirá posponer parte de ese trabajo, para tener una aplicación más eficiente con algunas advertencias. Ven a hablar conmigo después de la charla si quieres conocer más detalles.

Dejaré una última pepita interesante para que pienses en ello. He estado pensando en una sintaxis alternativa aquí, que es afirmar la pureza de un módulo, ¿qué significa puro en JavaScript? Excelente pregunta. Ven a hablar conmigo después. Pero esta puede ser una forma más interesante de indicarle al navegador que esto se puede cargar de forma perezosa. Puedes encontrar esto en la URL que se encuentra en la diapositiva. Actualmente está en la etapa uno y estoy solicitando comentarios. Después de todo, por eso estoy aquí, por esta propuesta.

Existe una propuesta contraria que no intenta resolver el mismo problema, pero nos brinda las herramientas para resolver el mismo problema en el que también estoy pensando, se llama import reflection. Divide el cargador de módulos en piezas que tú como desarrollador puedes programar tú mismo. En particular, el caso de uso es para WebAssembly. WebAssembly no siempre quiere instanciar un módulo como parte del gráfico de módulos. Esto te permite dividirlo y hacerlo en tu propio tiempo.

Finalmente, un problema interesante son los especificadores. Estoy seguro de que este es un problema que está cerca del corazón de todos. ¿Por qué escribir esto cuando puedes escribir esto? Ahora hay una propuesta que te permitirá hacer eso. Se llama import maps. Está en el WICG, el grupo de la comunidad de incubadoras web. Está implementado tanto en Chrome como en Firefox, pero no es una especificación web. Estamos esperando eso. Así que puedes molestar a esas personas para que lo incluyan en el W3C.

Un extra, import assertions y JSON modules. Lo menciono aquí porque esto te permite importar un módulo JSON. En la otra sala, hace unos cinco minutos, comenzó una excelente charla de Rick Hart sobre registros y tuplas, y aquí hay un pensamiento interesante, para las import assertions, en lugar de importar y afirmar que tienes un archivo JSON, tal vez tengas un archivo de solo lectura y es datos puros que no se pueden modificar. Eso es todo. Gracias.

9. Q&A: Origen de la increíble camiseta DOM

Short description:

Durante la sesión de preguntas y respuestas, el orador revela humorísticamente que robó la increíble camiseta DOM que lleva puesta a alguien del equipo DOM. Sin embargo, aclara que un miembro del equipo le dio la camiseta. Mencionan que ahora también trabajan en los DOM.

Genial, muchas gracias por tu charla. Pasaremos a la parte de preguntas y respuestas. Y comenzaremos con algunas de las preguntas más importantes. Las resolveremos primero. Entonces, ¿de dónde sacaste esta increíble camiseta DOM? La robé a alguien. ¿La robaste a alguien? Sí. Esto está en... No hagas esto. Está grabando ahora. No, me la dieron. La obtuve de alguien que trabaja en el equipo DOM, aunque ahora estoy obteniendo mi propia versión de esta camiseta porque ahora también trabajo en los DOM, así que... Sí, es... Genial. Bueno, quien haya hecho esa pregunta, aquí tienes tu respuesta. Hay otra pregunta. ¿Cómo se te ocurrió el nombre SpiderMonkey, si lo hiciste tú o alguien más? No se me ocurrió el nombre SpiderMonkey. De hecho, la persona que se le ocurrió el nombre SpiderMonkey fue Brendan Eich, el autor original del lenguaje JavaScript. No la especificación, porque eso vino después. La historia divertida sobre por qué se llama SpiderMonkey es que Brendan Eich estaba... SpiderMonkey es el segundo compilador de JavaScript. El primer compilador de JavaScript era algo diferente. SpiderMonkey es el segundo compilador de JavaScript que se ha creado. Era tan feo que Brendan Eich, que acababa de ir al zoológico con sus hijos, dijo que este es el código más feo que he visto y me recuerda al animal más feo que he visto, que es un mono araña. De acuerdo. ¡Vaya! Eso es un sentimiento. Bien. Creo que tenemos una pregunta real sobre el contenido, lo cual siempre es genial. ¿Hay diferencias entre los modules de ES, la implementación entre Mozilla y Chromium o WebKit de las que debamos estar conscientes? No. ¿No? Bueno, esa es una respuesta muy elaborada. No puede haber confusión sobre la respuesta. Como no tenemos más preguntas para ti, pero estoy seguro de que la gente sabe cómo encontrarte en el pasillo y en la sala de preguntas y respuestas más tarde. Seguiremos adelante. Me parece bien. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
WorkshopFree
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.