Construyendo un Motor de JavaScript en Rust: Lecciones de Boa

Gracias por invitarme aquí. Estoy emocionado de presentar esto y ser parte del evento. Me encantaría estar allí en persona, pero digital también está bien. Hablaremos sobre la construcción de un motor de JavaScript en Rust, lecciones de Boa. Veremos cómo nos va.

Pero antes de hacerlo, mi nombre es Jason Williams. Soy un ingeniero de software senior en Bloomberg. También soy delegado de TC39, que es el Comité de Estándares de JavaScript. Si tienes alguna pregunta de esta charla, puedes publicarla, creo, debajo de este video. O también puedes contactarme. Soy más activo en Blue Sky, así que puedes encontrarme allí. Mi dominio nombre, JasonWilliams.co.uk. También estoy en otros lugares, pero probablemente soy más activo en Blue Sky, diría yo.

Así que, sí, sobre mí. He sido un contribuyente de código abierto durante muchos años. Hace diez años, estaba realmente interesado en aprender más sobre navegadores, renderizado, pintura, diseño, ese tipo de cosas. Así que, contribuí a un proyecto llamado Servo, que es un proyecto de motor de navegador paralelo que fue mantenido por Mozilla en ese momento. Y fue esencialmente diseñado usando un nuevo lenguaje de programación en ese entonces llamado Rust para reemplazar Gecko, que era el motor en Firefox.

El lenguaje era muy nuevo. Así que, de hecho, incluso cuando escribías en ese lenguaje, podía estar cambiando debajo de ti. Así que, parte de la sintaxis que escribiste hace dos semanas ya no era válida. Y recuerdo que a menudo teníamos, como, formateadores y herramientas que simplemente iban y actualizaban toda la sintaxis de vez en cuando. No creo que haya hecho una contribución significativa al motor durante ese tiempo. Pero una cosa que hice, puede que haya sido la primera persona o una de las primeras en hacerlo funcionar en Windows. No funcionaba en Windows en absoluto en ese entonces. Así que, eso fue, yo era un usuario de Windows. Así que, ese era mi principal objetivo en ese momento. Estaba recopilando información de personas que estaba solo en las cabezas de las personas. Nada estaba escrito. Y esencialmente reuní todo eso, hice una guía para mí mismo.

Fue realmente para mi uso personal al principio. Y seguí esa guía y logré que Servo se iniciara en Windows y realmente quería compartir esto con el resto del mundo. Así que, tuve la suerte de poder hacer un blog en Mozilla Hacks hace casi diez años. 2017. Y estaba muy orgulloso de esto porque no solo mostraba al mundo que Servo está vivo y funcionando en Windows, sino que también permitía que más personas se involucraran frente a ti que no podían antes debido al sistema operativo en el que estaban.

Otra cosa que me llamó la atención sobre Servo fue la velocidad. Era bastante rendimiento. Esto se ejecutaba en Reddit en 2014. Estoy seguro de que ahora es incluso más rápido. Pero el motor CSS que fue escrito en Rust desde cero podía hacer uso de múltiples núcleos. Era muy concurrente. Creo que fue realmente uno de los primeros motores CSS concurrentes en ese momento. Y también tenía buena seguridad de memoria. Así que, todos estábamos muy confiados en él. Sabíamos que funcionaría bien. Realmente no había fallos. Pero también era muy rápido. Era más del doble de rápido que lo que Gecko tenía en ese momento.

Así que, básicamente, pensé, bueno, ¿podemos hacer esto con JavaScript? ¿Por qué no hacerlo en un motor de JavaScript? Y el equipo de Servo en ese momento estaba bastante ocupado. Así que, construir un motor de JavaScript no era algo en lo que estuvieran demasiado interesados en ese momento. Estaban bastante contentos de seguir usando Spider Monkey, que es el motor en Firefox. Así que, esencialmente me fui y jugué con algunas ideas. Y eventualmente comencé a trabajar por mi cuenta. Y ahí es donde entró Boa. El nombre, supongo que estaba tratando de seguir el tema de Mozilla de nombrar proyectos después de animales. Vi una serpiente en un zoológico en Sídney y pensé que realmente quería nombrar mi próximo proyecto después de eso. Así que, sí, lo que te mostraré es cómo comencé, realmente. Algunos principios del motor de JavaScript. No es exactamente cómo funciona Boa hoy. Pero es un poco de una visión, realmente, de dónde comenzaron las cosas.

Hay algo de código en Rust en esto también. La ironía no se me escapa de que esta es una conferencia de JavaScript. Pero los principios son los mismos. Cualquiera que sea el lenguaje en el que intentes construir un motor de JavaScript. Intentaré mantenerlo lo más alto nivel posible.

Así que, sí, una cosa que aprendí rápidamente es que los motores de JavaScript son tuberías o líneas de ensamblaje de fábrica o como una planta de procesamiento. El trabajo se divide en etapas. Cada etapa, ya sabes, tienes alguna entrada. La transformas. La pasas hasta que, ya sabes, finalmente terminas con el resultado final. Que generalmente es ejecutar tu código.

Quiero decir, la ejecución ni siquiera necesita ser el resultado final. El resultado final podría ser otro lenguaje. Así que, un transpiler que toma un lenguaje de nivel superior y escupe un lenguaje de nivel inferior o ensamblador o algo así. Lo que tengo es lo que llamamos un tree walker. Y el nombre se hará evidente en un minuto. Y así, estas son las etapas que comencé a juntar. Tienes la etapa de tokenización. Aquí es donde el motor toma el código fuente bruto de JavaScript y lo descompone en piezas más pequeñas. Vamos a llamar tokens.

Tenemos la etapa de análisis. Que toma esos tokens, los convierte en una representación estructurada para reflejar, supongo, la gramática del lenguaje, la estructura del lenguaje. Eso luego nos da el árbol de sintaxis abstracta o el AST. Y eso representa el código de la manera que el motor realmente puede trabajar con él.

Y verás eso en unos minutos. Una vez que tenemos eso, podemos ejecutarlo. Y luego obtenemos nuestros resultados finales. Obviamente, esto está simplificado.

Sabes, motores como V8 o incluso Boa hoy en día tienen muchos más pasos entre estos. Pero cuando estás comenzando, esto es básicamente como lo veía. Pero antes de nada de eso, realmente necesitamos leer un archivo. Así que, este es solo un código simple de Rust. Principalmente muestro esto por dos razones. Una es porque es un recordatorio de que también estaba aprendiendo la biblioteca estándar de Rust así como aprendiendo a construir un motor JS. Si alguna vez quieres aprender dos lenguajes al mismo tiempo, puedes construir un lenguaje con el otro y obtienes una buena comprensión de ambos. La segunda razón por la que muestro esto, y por cierto, esto es, sí, si no es evidente, esta es una biblioteca estándar para leer un archivo en una cadena. Así que, el buffer a la izquierda es la variable de cadena. Y con Rust, tienes que manejar tus errores. Así que, el expect aquí es esencialmente impreso si algo falla durante la lectura. Y, sí, la segunda razón por la que muestro esto es solo para mostrar que en realidad este fue el primer commit. Así que, no estoy si no me crees, puedes ver aquí, commit uno, 8 de agosto de 2018 es yo tomando el archivo JS y simplemente imprimiéndolo. Así que, comienza simple. Sabes, realmente no puedes hacerlo más simple que eso. Puse eso en un archivo, hice un repo, y luego comencé desde allí.

Así que, tenemos nuestra cadena, está almacenada en una variable, y necesitamos tokenizarla. Y aquí es donde el motor toma, sí, el código fuente de JavaScript en bruto y lo descompone. Es un poco como la salchicha saliendo de la fábrica y la estás cortando en versiones más pequeñas de sí misma, si es una analogía para usar. Pero nosotros, sí, tenemos nuestro let foo equals hello world. Y tenemos nuestro escáner o cursor que se mueve letra por letra hasta que encontramos un espacio, y luego ese es nuestro primer token. Así que, puedes ver aquí que estamos viendo esto en una especie de base carácter por carácter. Encontrando un espacio y luego creando tokens a partir de él. Así que, aquí tenemos una palabra clave. Tenemos nuestro identificador. Tenemos una puntuación o un punctuator. Y luego tenemos un literal de cadena. Y podrías preguntarte, bueno, ¿cómo sabemos que estos son tipos de token? ¿Cómo sabemos qué tipos de token hacer? ¿Cómo sabemos cuál es cuál? Bueno, afortunadamente para nosotros, tenemos la especificación ECMAScript. Mencioné antes que soy un delegado de TC39, así que soy muy afortunado de haber ayudado también a contribuir a la especificación. Pero este documento está abierto para cualquiera.

No está detrás de, ya sabes, puertas cerradas o pagos o algo así. Cualquiera puede visitar la especificación ECMAScript. La mayoría de los autores de motores lo hacen. Puedes obtener mucha información que necesitas de aquí. Por ejemplo, nombres de tokens o tipos de tokens. Así que, puedes ver aquí que tenemos varios tokens, nombres de identificadores, puntuadores, literales de cadena. Y si te desplazas un poco hacia abajo en esta página, puedes ver que también tenemos una lista de palabras clave. Así que, podrías tomar estas palabras clave, codificarlas en tu propio motor, y luego verificarlas para ver si un token es una palabra clave. Si lo es, sabes qué tipos de token darle.

Así que, volviendo a nuestro ejemplo. Tenemos una estructura de token, que es un poco como un objeto en JavaScript. Tiene dos propiedades. Tenemos datos de token, y puedes ver que tenemos todos los diferentes tipos de tokens allí. No coincide completamente con lo que teníamos en la especificación, pero está bien. Y luego tenemos una posición donde está o donde lo encontramos en el código fuente. Útil para depuración más tarde. Y luego, una vez que hemos creado nuestro token, va a nuestro array. Así que, aquí tenemos cuatro tokens, palabra clave, identificador, puntuación y literal de cadena. Y puedes ver justo arriba he puesto lo que cada token está sosteniendo actualmente. Así que, puedes ver let foo equals hello world. Una vez que tienes eso, has terminado, y eso puede ser enviado al analizador.

Así que, el analizador pasará por estos tokens, como tenemos aquí, de izquierda a derecha. Y para cada uno, no solo estamos preguntando qué viene después, sino que los estamos tomando y estamos construyendo un árbol, un árbol de sintaxis abstracta que representa la estructura de lo que es el programa. Vamos a pasar de esto, lo que tenemos aquí, a algo que se ve así. Y esto es una declaración léxica. Así que, podemos ver la letra en la parte superior. Y decimos, está bien, una declaración léxica debe tener una variable. Así que, la variable está directamente debajo. E incluso la variable y lo siento, es un array de variables, aunque solo tenemos una. Por eso tenemos los corchetes y la variable, porque puedes definir y declarar múltiples variables en una declaración.

Y cada variable tiene un nombre de enlace y un iniciador. El iniciador es realmente opcional. Puedes simplemente hacer let foo y seguir adelante. Pero esencialmente, obtienes un árbol que se ve así a la derecha. Y cuando estaba armando esto en Rust, en realidad era algo un poco como esto.

Así que, nuestra declaración léxica es un nodo AST. Entonces, lo que está en la línea dos es un enum. Y eso es porque let y const son declaradores léxicos. Var es un poco diferente. Tiene diferentes semánticas con los alcances de función. Así que, tiene su propio nodo. Y, sí, puedes ver que es solo un enum con let y const y cada uno tiene una lista de variables.

Y para ver cómo se ve una variable, puedes ver la línea siete, tenemos un enlace y un iniciador. Este enum en la línea dos, en realidad puedes darle métodos. Así que, podemos crear un método de pase. Y debido a que nuestro primer token fue el let, sabemos que estamos tratando con una declaración léxica, así que llamamos a pars en eso y eso debería encargarse del resto por nosotros. Así que, podemos ver aquí en la línea cuatro, por ejemplo, esperamos que el siguiente token sea un identificador.

Y el signo de interrogación al final de la línea cuatro está diciendo esencialmente, bueno, propaga el error hasta arriba si no lo es. Así que, esencialmente, estamos terminando el programa allí. Es un error de sintaxis. No necesito continuar más allá. Aquí, en la línea siete, estamos esencialmente verificando si el siguiente token después del identificador es un signo igual. Si no lo es, entonces simplemente decimos, está bien, es una vinculación sin nada definido en ella. Y simplemente devolvemos non. Así que, tenemos suficiente información aquí para devolver un tipo de variable que tiene un nombre de enlace y un iniciador o un iniciador opcional.

En realidad, se ve así cuando está todo junto. Así que, puedes ver nuestra declaración léxica. Está sosteniendo un array de una variable que tiene un identificador foo y hello world. La ejecución es realmente bastante simple porque hemos hecho la mayor parte del trabajo por adelantado. Así que, como dije antes con este tipo, volviendo a esto, como mencioné antes que le dimos a este tipo un método llamado pass. También podemos darle otro método llamado execute.

Así que, puedes ver el impl en la línea uno. Si no lo describí antes, me disculpo. Esencialmente nos permite agregar un método a ese enum. Y ahora podemos ejecutarlo. Hemos puesto los valores allí. Y ahora los valores están allí, podemos realmente ejecutarlo. Así que, lo que está sucediendo aquí es que hacemos un patrón de coincidencia primero en el valor en sí. ¿Es un let? ¿Es un const? En este caso, lo mismo sucede independientemente. Sacamos las variables y las almacenamos en VARS en la línea tres. Y luego en la línea ocho, recursamos, hacemos un bucle a través de las variables.

En este caso, solo hay una. Esto solo se ejecuta, solo tenemos una iteración de esto. Si hay un iniciador en la línea 10, llamamos a execute en la expresión. Así que, aquí es donde viene el nombre, el recorrido del árbol. Porque si la declaración léxica tiene un execute, eso llamará a execute en los nodos debajo de eso. Lo que luego llamará a execute en los nodos debajo de eso. Hasta que finalmente obtenemos un valor, que es lo que tenemos en la línea 10. Así que, es bastante recursivo.

Luego declaramos nuestro nombre de variable en nuestro contexto con nuestro valor. Y no he hablado mucho sobre el alcance y el contexto en esto. Creo que eso está un poco, un poco, bueno, fuera de alcance para esto. Pero esencialmente el alcance es un mapa hash que representa el alcance actual. Y luego esos mapas hash tienen padres. Así que, si una variable no está allí, entonces recursará hacia arriba y así sucesivamente. Pero puedes ver aquí, es bastante sencillo. Lo que nos queda es un enlace foo que se ha creado con un valor de JavaScript, que es una cadena de hello world.

Así que, eso fue un recorrido rápido de las cosas que configuré en las etapas iniciales. Fue bastante ingenuo como implementación. Nunca había construido un motor de JavaScript antes. Pero afortunadamente, ha tenido unos años para crecer. Y así, hoy, me complace decir que hemos avanzado bastante desde entonces. Pero definitivamente fue un buen comienzo. Tenemos una máquina virtual. Así que, en lugar de ejecutar a medida que avanzamos, ahora tenemos generación de código de bytes. Eso es mucho más compacto. Hace que la reutilización de ciertas rutinas sea más rápida.

Más cosas están en caché en la CPU. Estamos haciendo menos ida y vuelta a la memoria principal. Entonces, significa que la ejecución general es mucho más rápida. También tenemos almacenamiento en caché en línea. Entonces, la búsqueda de propiedades en varios objetos es mucho más rápida de lo que era hace un par de años.

Hemos logrado construir un equipo de mantenedores. Entonces, las cosas que te mostré antes eran principalmente solo yo. Era principalmente solo yo mismo trabajando en Boa durante los primeros años. Logramos que algunas personas se unieran.

Comenzaron haciendo uno o dos PRs y luego decidieron que querían involucrarse en el proyecto. Así que, tuvimos una muy buena comunidad de contribuyentes a lo largo de los años. Estoy muy orgulloso.

Volveré a eso. Pero sí, nos ha ayudado a armar una API abierta que es bastante estable. Entonces, tenemos bastantes usuarios. Si conoces Biome, ellos usan Boa para sus extensiones. Y tenemos soporte para varias otras cosas también.

He puesto soporte async aquí, promesas, y cualquier tiempo de ejecución asincrónico que quiera usar Boa, funciona bastante bien. Solo quiero destacar la comunidad. Una cosa que realmente ha funcionado bastante bien para nosotros es desde el primer día al trabajar en Boa, quería asegurarme de que fuera algo a lo que otras personas pudieran contribuir y trabajar. Me costó contribuir a otros motores de JavaScript antes de comenzar con Boa.

Así que quería hacerlo lo más fácil posible. Sabía que nunca podría construir un motor de JavaScript completo por mi cuenta. Y definitivamente era algo con lo que necesitarías ayuda. Así que, hacer que fuera fácil para las personas contribuir, para mí, era bastante importante. Entonces, dicho esto, siempre me aseguré de que, ya sabes, el código fuera bastante fácil de seguir, ya sabes, comentando sobre varias cosas. Si algo funcionaba, pero no estaba del todo contento con ello, a menudo intentaba comentar y decir, tal vez podamos intentar esto en el futuro o, ya sabes, tareas pendientes y cosas así.

Documentación. Entonces, en Rust, en el ecosistema de Rust, ya sabes, tenemos docs.rs, que alojará documentación para ti si publicas tus crates en crates.io. Siempre traté de asegurarme de que la documentación fuera buena. Aunque solo estaba yo trabajando en ello por mi cuenta y no había nadie más colaborando, aún así traté de asegurarme de que los documentos fueran buenos. Buenas primeras issues. Siempre las encuentro bastante acogedoras y útiles. Personalmente me gustan y las veo en otros proyectos.

Así que trato de asegurarme de que los problemas estén categorizados en fáciles, medianos y difíciles. Y algunos buenos primeros para elegir también. Y cuando la gente elegía esos que no estaban seguros sobre el repositorio o el proyecto, trataba de ayudar en las solicitudes de extracción. Estoy muy feliz de decir que teníamos algunos mantenedores. Ahora somos unos cinco o seis. Así que trasladamos Boa a una organización, creo que en 2020. Antes de eso, estaba solo bajo mi propio nombre. Y luego también me aseguré de que los mantenedores tuvieran acceso para, ya sabes, revisar y fusionar solicitudes de extracción también.

Así que, eliminó ese factor de autobús de que todo tuviera que pasar por mí, lo cual no sería muy fácil hoy en día. Y luego, por supuesto, teníamos Discord y Matrix. Así que, para mí, sí, construir una comunidad fue bastante importante y realmente nos ha ayudado mucho.

Dicho esto, pruebas. La razón por la que mencioné las pruebas después del aspecto comunitario de esto es porque las pruebas aumentaron masivamente una vez que tuvimos gente trabajando en Boa. Nicholas P. Pierron de SpiderMonkey me dijo, ya sabes, hazlo correcto primero, siempre puedes acelerarlo después. El orden en el que siempre he hecho esto es una implementación ingenua que sigue la especificación y podemos preocuparnos por el rendimiento más adelante. Tuvimos a alguien llamado Iban que se unió a Boa. Ha estado con Boa desde creo que 2019 hasta 2020. Y ayudó a construir un pequeño arnés de prueba que se ejecutó contra el conjunto de pruebas de especificaciones ECMAScript llamado Test 262.

En 2020, teníamos un 18% de conformidad. Probablemente no puedas verlo muy bien. Pero Iban también tenía estos pequeños puntos, los puntos rojos, podías ver fallar y creo que había uno que apenas podías ver para aprobar. Pero a lo largo de los años, la gente trató esto como un desafío y tuvimos todo tipo de contribuyentes que vinieron a nosotros y trataron masivamente de arreglar cualquier prueba que encontraran. Realmente me gusta esto. Este es nuestro progreso de pruebas a lo largo del año. Así que, creo que la izquierda es alrededor de 2019, 8,000 pruebas aprobadas. Y puedes ver el, sí, puedes más o menos ver el, supongo, el gráfico de aumento de las pruebas aprobadas en verde para cuando llegas a, creo que llega a 2024, estamos alrededor de 75 pruebas aprobadas. Así que, eso es realmente bueno. Si entras en el sitio web hoy, se ve un poco así. Así que, es un poco más aburrido.

Ya no tenemos ese gráfico. Necesitamos traerlo de vuelta. Renovamos el sitio web. Y así, ahora estamos viendo alrededor de 51,000 pruebas aprobadas de un total de 53. Entonces, en realidad, el número de pruebas totales ha disminuido desde esto. Y eso es porque Test 262 eliminó algunas pruebas. Pero estamos bastante bien en realidad en conformidad. Hay un sitio web llamado test262.fyi. Y eso ejecuta motores cada noche y recopila los resultados de cómo están haciendo en las pruebas. Y estamos en cuarto lugar en este momento. En realidad, estamos por encima de JavaScript Core, que es un motor de JavaScript de Safari. Así que, actualmente estamos al 95.5% de aprobación en todo el conjunto.

Y justo antes de irme, quiero mencionar rápidamente Temporal. Entonces, el equipo de Boa decidió que queríamos implementar Temporal. Esto fue alrededor de 2024 cuando comenzamos a trabajar en esto. Es la característica más anticipada en JavaScript en este momento. Y para nosotros, las cosas realmente comenzaron a mejorar alrededor de este tiempo. Pero lo emocionante es que colaboramos con V8 e Intel, el equipo de Google Intel, detrás de Chrome. Y decidimos trabajar juntos en una biblioteca independiente en Rust llamada Temporal RS.

Y durante 2024 y 2025, formé un equipo. Ha sido algunos de los mantenedores de Boa, yo mismo, Manish de Google, y hemos tenido estudiantes de la Universidad de Bergen, seis estudiantes de Bergen University se unieron a nosotros también. Pero Temporal RS no solo ha estado funcionando y completo, sino que ahora pasa el 100% de las pruebas para el conjunto Temporal en test262. Así que, eso es aproximadamente alrededor de 5,000 pruebas que Temporal pasa. Y así, debido a eso, ha llegado a V8, y en realidad se ha lanzado en lo que puedes ver aquí, lanzado en Chrome, 144, 6 de enero. Node.js, que solo salió recientemente, lanzamiento del 5 de mayo, ha estado en Deno por un tiempo. Y por supuesto, Boa lo ha tenido por un tiempo también detrás de la bandera. Así que, estoy realmente, realmente orgulloso de este trabajo que hemos logrado hacer.