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

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.

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í.

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.

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.

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.

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.

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.

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.

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.