Cómo funcionan los Módulos JS: una Perspectiva del Navegador

Esa es una introducción muy genial. Por cierto, si alguien está pensando, oh, ¿qué pregunta debería hacer en el Q&A? , pregúntame sobre cómo obtuvimos el nombre SpiderMonkey.

Es una historia divertida. Así que hola a todos. Vamos a hablar sobre 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 ingeniera de software en Mozilla. En particular, trabajo en SpiderMonkey, que es el compilador de JavaScript para Firefox. De hecho, no es solo JavaScript, también hacemos WebAssembly. La parte en la que trabajo es el lado de JavaScript. También hago un poco de trabajo 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 estaba como, no sé cómo voy a unir todo esto y hacerlo entretenido. Esto es un poco seco. Y me encontré con este gran tweet de mi excolega, Jason Orndorff. Solía trabajar en SpiderMonkey conmigo y aprendí mucho de él. Especialmente sobre diseño de lenguajes y lenguajes. Escribió este gran... Llamémoslo un invariante de todos los lenguajes de programación que implementan un método de reversa de cadena. Incidentalmente, JavaScript no implementa el método de reversa de cadena. Pero efectivamente, string.

reverse en cualquier lenguaje en el que lo pruebes no revertirá una imagen de un pez. Aquí tenemos un ejemplo de tal 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, de hecho, el pez sigue mirando en la misma dirección. Podríamos decir que este pez es invariante, una palabra importante que usaremos. Así que el pez es nuestro tema, y dado que tengo al pez como tema, puedo usar uno de mis chistes de apertura favoritos de una conferencia magistral que proviene de David Foster Wallace en su conferencia magistral de 2005 a una universidad, que va algo así. Dos peces están nadando en el océano y simplemente ocupándose de sus propios asuntos. Son jóvenes. Son nuevos en este hermoso mundo azul, y un pez más viejo pasa nadando y dice, ¿cómo está el agua, chicos?

Un poco más tarde, los dos peces siguen nadando en silencio cuando uno de los peces se gira hacia el otro y dice, ¿qué demonios es el agua? Este es un gran chiste para preparar el escenario para algo que podríamos dar por sentado, para algo que existe en el éter y parece que simplemente está ahí, algo que no necesitas cuestionar.

Eso 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 usan como su forma principal de escribir módulos de JavaScript, especialmente la sintaxis de importación-exportación. ¡Oh, sí, olvidé arreglar eso! ¡Por alguna razón tengo eso dos veces! ¿Cómo llegamos aquí?

Una pregunta que podrías hacer es, bueno, los módulos, ¿cuándo comenzaron? ¿Cuántos años tiene este problema? Tengo parte de una respuesta aquí para ti. No puedo darte una respuesta definitiva, pero aquí hay una base de código que es un fragmento de 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 título de máster.

Para muchos de ustedes en la audiencia, es probable que los módulos realmente llegaron a la vanguardia con la introducción de Node. En particular, esta publicación de blog de 2009 por Kevin Dengar es un punto de referencia importante, porque aquí está preguntando, él también es un ex empleado de Mozilla, está preguntando, ¿qué necesita 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 comunitario llamado el grupo comunitario de server JS. Este grupo fue renombrado más tarde a common JS, lo cual imagino que suena bastante familiar. Como se mencionó, seis años después, en 2015, los módulos ES6 finalmente se introdujeron en la especificación. Los navegadores tardaron un poco más en implementarlo. Llegaron en 2018. Introdujo una serie de características al navegador, incluida la sintaxis de importación-exportación con la que muchos de ustedes están familiarizados.

Vamos a entrar 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 de common JS? ¿Por qué no especificamos common JS? Eventualmente, llegaremos a cómo se ve la característica para el sistema de módulos en los navegadores. Una cosa para comenzar es que el sistema de módulos construye un gráfico. Este gráfico permite ciclos. Si tienes un módulo importando algún vecino, y ese vecino importa un ancestro de tu módulo inicial, esto funcionará. Es una característica importante para la ergonomía del desarrollador. No quieres estar rompiendo ciclos manualmente todo el tiempo. El navegador hace esto por ti. Entonces, ¿cómo construimos realmente este gráfico? ¿Cómo funciona? ¿Cómo aseguramos que realmente puedas escribir tus módulos de esta manera cíclica? Voy a comenzar tomando la perspectiva de un nodo. El nodo, en este caso, en este gráfico, va a ser un único script de módulo. En la especificación, tenemos una estructura de datos llamada el 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 para la implementación de Mozilla de esto 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 imports y exports, y el campo de imports define una serie de claves que son, por ejemplo, lo que podrías llamar un nombre de variable, al igual que los exports, definen una serie de claves, la diferencia es que los imports usan el especificador de URL para el hijo dado que queremos importar, y los exports apuntan a una pieza específica de código que va a 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 voy a contar cómo funciona en common JS, porque el contraste es importante, especialmente para discusiones posteriores. Digamos, esto es, vamos a pretender que este es el caso típico para common JS. Escribes un fragmento de código y tienes un bloque de JavaScript que está haciendo algún tipo de trabajo, luego llegas a una declaración require. En este caso, el trabajo que estamos haciendo es crear una ruta dinámica, y luego estamos requiriendo esa ruta y cargándola. El navegador ya ha hecho el paso de cargar este script, lo ha analizado, y ahora lo está ejecutando, por lo que pausa la ejecución y procede a hacer 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, regresamos a nuestro módulo anterior y continuamos ejecutando.

Entonces, ¿cuál es el problema con este diseño? ¿Por qué no implementamos esto? El problema es que notarás que no hay sintaxis de promesa aquí en ninguna parte, y por supuesto common.js fue antes de await a 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. Voy a darte 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, es como un segundo para acceder a la memoria principal, estás viendo alrededor de seis segundos o así. Si quieres obtener la memoria principal siendo RAM, si quieres obtener algo de la red en esta escala de tiempo, estás viendo alrededor de cuatro años. Este es un trozo de tiempo realmente significativo que vas a pasar en la red. Además, hay un invariante importante de la plataforma web, se llama ejecución hasta completar. ¿Qué significa ejecución hasta completar? Si has estudiado sistemas operativos, puede que estés familiarizado. Pero si no lo has hecho, ejecución hasta completar significa que una tarea dada continuará ejecutándose hasta que voluntariamente ceda su 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 continuará bloqueando. Eso 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. Así que 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 common JS está cargando, analizando y evaluando el módulo todo en un paso. En ES6, hacemos eso 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 del gráfico, así que, yo soy mis vecinos, estos son mis bordes entrantes, estos son mis bordes salientes. Una vez que tenemos esto, también tenemos los imports, las otras URLs que necesitamos cargar, así que podemos proceder a cargar otro script. A medida que cargamos ese otro script, podemos ir y 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 y obtención. Es una pieza importante de cómo el sistema de módulos difiere de common.js.

Una pregunta importante que podrías estar preguntándote es cómo implementas ese comportamiento de bucle de módulos? ¿Cómo rompes bucles y aseguras que no entres en un bucle infinito de módulos importándose continuamente entre sí? La respuesta a eso se encuentra en una estructura de datos global que representa nuestro gráfico. Ahora eso se llama el mapa de módulos. Puedes encontrarlo en la especificación si lo deseas, y rápidamente repasaré cómo el mapa de módulos nos ayuda a romper ciclos cuando estamos cargando módulos.

Una nota importante que voy a hacer aquí, verás que el origen de estas URLs está en rojo. Es importante notar que tenemos que trabajar con URLs y son URLs completamente resueltas que podrías realmente escribir en tu navegador y resolverlo 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 reemplaza esa URL relativa con una URL completamente resuelta. Pero comencemos con cómo el mapa de módulos resuelve ciclos en el gráfico. Comenzamos en un estado llamado no enlazado. No hemos establecido relaciones entre vecinos en el gráfico, y main.js es nuestra raíz, path.js es el hijo inmediato, y otro módulo que es el hijo inmediato de path.js.

Main.js comienza su proceso de enlace, voy a ir y mirar a mis hijos. Ve que tiene un hijo y comienza a hacer lo mismo. Path dice tengo hijos, voy a comenzar a enlazar. Otro módulo es el siguiente en el algoritmo y dice es mi turno de comenzar a enlazar. Pero no tengo hijos, así que ahora estoy automáticamente enlazado. Ese es mi estado por defecto. Porque otro módulo se ha enlazado, path.js dice todos mis hijos ahora están enlazados, eso significa que yo también estoy enlazado. Main.js dice todos mis hijos están enlazados, por lo tanto yo también estoy enlazado. Luego introducimos el ciclo, que es importar path.js. Va a ir y mirar a path.js. Aquí es donde ocurre la ruptura del ciclo. Porque path.js ya está enlazado, terminamos el algoritmo allí, e importar path.js puede decir que también está enlazado. 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 obtención, y la otra es la tabla hash obtenida. Lo que nos dice qué estamos cargando actualmente y qué ya hemos cargado. Nos previene de recargar cosas de la red. Los enlaces están todos allí. La siguiente pregunta es por qué estamos usando URLs? La razón por la que estamos usando URLs es que tenemos que saber dónde buscar, y antes de una cierta propuesta de la que vamos a hablar en un segundo, no había forma de determinar cuál era la ubicación y sin la ubicación no podemos obtener 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 por el 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 conseguir eso para mí?, Gekko dice, claro, puedo conseguir eso para ti. Aquí están los contenidos de ese archivo. SpiderMonkey procede y lo analiza. Genial, acabamos de terminar el bucle que discutimos hasta este punto. Ahora, el siguiente paso aquí es cómo instanciamos este módulo? La instanciación significa tomar este registro de módulo y convertirlo en un pedazo de código vivo y en funcionamiento. Ahora, ¿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 pedazo de código. Así que tendrías múltiples de ese estado y múltiples del código ejecutándose. En ES6, es todo un singleton. Tenemos algo llamado enlaces en vivo. Si este pez muere, será visible a través de 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 gráfico dado. Eso viene 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 ir y recorrer los hijos hasta el final y comenzar desde la ejecución del ú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.

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

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

Así que tuvimos esta pregunta, ¿qué demonios es el agua? De qué he estado hablando. Acabo de decirte cómo funciona el sistema de módulos en los navegadores, pero en realidad no se está usando tanto, el sistema de módulos no está siendo golpeado por el código. Un problema es la velocidad de la red. Este es el problema que mencionamos antes cuando discutí la 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 golpes 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 estamos mirando desde una perspectiva de desarrollador, hay otras propuestas más interesantes potencialmente, espero, que pueda mostrarte. Podemos seguir hablando de este problema más amplio de rendimiento que es algo que detiene la adopción de módulos.

Recuerda que tenemos un 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 preempción, no tenemos forma de reordenar tareas, tienen que ejecutarse hasta la finalización. El otro invariante que no he mencionado aún 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 ejecutamos eso primero, significa que si has concatenado eso en un solo archivo grande, el comportamiento de un archivo concatenado es el mismo que el módulo cargado. Así que, esta es una propuesta que he escrito que actualmente está en la etapa uno, se llama evaluación diferida de módulos que está tratando de abordar este problema. Tenemos, digamos, un archivo JavaScript con una importación que ha sido este archivo JavaScript ha sido escrito para la mejor legibilidad posible desde la perspectiva de un programador. Así que tenemos una importación estática y luego tenemos varias funciones raramente usadas que eventualmente usarán este código.

Pero eso significa que no necesitamos cargar esta información inmediatamente al frente. Todo esto sucede, tal vez, un minuto después de la ejecución de la aplicación, lo cual podríamos hacer una carga entre medio. Entonces, ¿cómo solucionamos esto? Podrías escribir un método perezoso que haga una importación dinámica del archivo que originalmente te interesaba, 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 está cambiando semánticamente cómo funciona ese código. Lo cual 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 import, 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 que puedas tener una aplicación más eficiente con un par de advertencias. Ven a hablar conmigo después de la charla si quieres escuchar más detalles.

Dejaré solo un dato interesante más para que lo pienses. He estado pensando en una sintaxis alternativa aquí, que es para afirmar la pureza de un módulo, ¿qué significa puro en JavaScript? Excelente pregunta. Ven a hablar conmigo sobre eso después. Pero esta puede ser una forma más interesante de insinuar al navegador que esto puede cargarse de manera perezosa. Así que, puedes encontrar esto en la URL que encuentras en la diapositiva. Actualmente está en la etapa uno, y estoy solicitando comentarios. Por eso estoy aquí, después de todo. Sobre esta propuesta.

Hay una contrapropuesta que no intenta resolver el mismo problema, pero nos da 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 grafo 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 uno 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 comunitario 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 lleven al W3C.

Un extra, import assertions y JSON modules. Estoy mencionando esto aquí porque esto te permite importar un módulo JSON. En la otra sala, hace unos cinco minutos comenzó, hay una excelente charla de Rick Hart hablando sobre records y tuples, y aquí hay un pensamiento interesante, para import assertions, en lugar de afirmar que tienes un archivo JSON, tal vez tengas un archivo de solo lectura y es un dato puro que no se puede modificar. Eso es todo. Gracias.

Genial, muchas gracias por tu charla. Pasaremos a la pequeña sesión de preguntas y respuestas. Y comenzaremos con algunas de las preguntas más importantes. Las sacaremos del camino primero. Entonces, ¿de dónde sacaste esta increíble camiseta de DOM? La robé de alguien. ¿La robaste de alguien? Sí. Esto está en... No hagas esto. Está grabando ahora. No, me la dieron. La obtuve de alguien que trabaja en el equipo de DOM, aunque estoy consiguiendo mi propia versión de esta camiseta porque ahora también trabajo en los DOMs, así que... Sí, es... Genial. Bueno, quien haya hecho esa pregunta, aquí está tu respuesta.