Crea tu propio tiempo de ejecución de JavaScript

Hola, gente. Mi nombre es Bartek, y soy del equipo de Deno, y bienvenidos a su propio tiempo de ejecución de JavaScript. Un poco sobre mí. Comencé a contribuir a Deno en 2018, y luego me convertí en empleado de la compañía a fines de 2019, y he estado con la compañía desde entonces. Actualmente lidero el equipo de CLI de Deno, y si tienen alguna pregunta o seguimiento, no duden en comunicarse a través de uno de los enlaces proporcionados aquí. Entonces, en esta charla, vamos a hablar un poco sobre cómo crear o desarrollar su propio tiempo de ejecución personalizado de JavaScript. No vamos a hacer esto desde cero. Esta charla se basa en un par de publicaciones de blog que hicimos en el pasado. Creamos un pequeño tiempo de ejecución de JavaScript llamado Run.js, y pueden seguir los enlaces y la grabación aquí si desean aprender un poco más sobre la historia del proyecto. Bueno, en nuestra opinión, es bastante fácil comenzar si desean crear su propio tiempo de ejecución de JavaScript. Gracias a las tecnologías que podemos usar ahora, que son el motor para ejecutar JavaScript, pero también parte de la infraestructura que el equipo de Deno proporciona. Entonces, sin más preámbulos, vamos a meternos de lleno en esto. Pero antes de hacerlo, necesitamos aprender un poco más sobre Deno en sí mismo. Deno es un tiempo de ejecución de JavaScript y TypeScript. Su objetivo es ser divertido y productivo de usar. Deno admite la importación de códigos fuente desde un sistema de archivos, desde servidores remotos utilizando los protocolos HTTP o HTTPS, y también admitimos importaciones de NPM utilizando estos especificadores de columna de NPM. Deno es un tiempo de ejecución de TypeScript en el sentido de que no es necesario compilar explícitamente sus fuentes de TypeScript a JavaScript antes de ejecutarlas. Deno puede encargarse de eso por ustedes. Puede transpilar las fuentes, pero también puede verificar los tipos. Deno está construido utilizando Rust y el motor de JavaScript, por lo que en cierto sentido es muy similar a Node.js porque ambos utilizamos el mismo motor de JavaScript. Sin embargo, Deno utiliza Rust para su código nativo, mientras que Node.js utiliza C++. Deno viene con todo incluido. Tenemos muchas herramientas que les permiten comenzar en segundos. Tenemos Formatter, TestRunner, Linter. Incluso pueden crear un binario autocontenido, es decir, empaquetarán todo el código fuente que proporcionen y luego les dará un solo archivo ejecutable. Es algo similar al paquete PKG MPM que pueden usar. Deno también está muy involucrado en las API web. Tenemos muchas de ellas, especialmente Fetch, TextEncoder, TextDecoder, Blob. También tenemos soporte para la API de WebStreams y la API de WebWorker. Hay muchas, muchas más de estas API y les sugiero que visiten el MDM

Consulten la página de la API en la que estén interesados y vean si Deano admite la API. Deano en Rust es, bueno, necesitamos entender un poco de historia aquí en que la primera iteración de Deano, el primer prototipo, no se escribió realmente en Rust. En cambio, se escribió en Go. Sin embargo, debido a la naturaleza de Go, que es recolectado por basura al igual que JavaScript, se decidió que deberíamos alejarnos de Go para evitar una situación en la que dos recolectores de basura compitan entre sí. Así que Deano se escribió en Rust, que es un lenguaje de bajo nivel o lenguaje de sistemas que no tiene un recolector de basura. Y puedo decir que esta es probablemente la decisión más influyente que se haya tomado para el proyecto Deano. Rust nos permite avanzar muy rápidamente y nos permite aprovechar un enorme ecosistema de crates disponibles. La mayoría de las crates son de muy alta calidad, por ejemplo, una crate http que implementa el protocolo http está muy bien probada y tiene una gran cobertura, por lo que tenemos mucha confianza en usarla y cumplir con el protocolo definido. Y por último, pero no menos importante, construir Deano es realmente muy sencillo. Dado que Deano está completamente integrado con Cargo, que es la herramienta de construcción o sistema de construcción de Rust, es solo un comando para compilar todo el binario de Deano, incluido V8, pero no realmente. No te obligamos a compilar V8 tú mismo, en su lugar lo hacemos en nuestra canalización de CI para que puedas usar archivos binarios precompilados, lo que te ahorra muchos problemas, ya que V8 es un proyecto enorme que lleva bastante tiempo compilar. Otra cosa es que Deano no es un monolito. Rust te proporciona una forma sencilla de separar las piezas de tu código en lo que se llaman crates. Las crates son equivalentes a los paquetes npm, por lo que son bibliotecas autocontenidas y reutilizables que puedes descargar y usar cuando quieras y Deano, el CLI que puedes descargar, en realidad es una colección de estas crates que están entrelazadas y están diseñadas para funcionar muy bien juntas. Por lo tanto, una de las consecuencias es que en realidad, en Deano aquí en la empresa Deano, en realidad no enviamos solo un runtime. En realidad enviamos dos runtimes diferentes. Tenemos el CLI de Deano, pero también tenemos Deano deploy, que es nuestra oferta en la nube. Estos runtimes son muy similares, sin embargo, no son idénticos. El CLI de Deano está orientado al desarrollo local y a implementar tu código en tu propio servidor o Lambdas, mientras que Deano deploy está orientado a ser implementado en contenedores nativos en la nube y similares. Por lo tanto, como usuario, puedes elegir qué crates y APIs necesitas y luego puedes combinarlos para crear tu propio runtime que se adapte a tus necesidades. Volviendo a nuestro ejemplo de runtime run.js. ¿Qué puede hacer en este momento? Bueno, son solo 140 líneas de Rust y 37 líneas de JavaScript, por lo que no es mucho código, pero ya tiene soporte para módulos ES. Puede transpilar JavaScript a TypeScript sobre la marcha justo antes de la ejecución, similar a cómo lo hace Deno. Tenemos una API para leer un archivo, una API para escribir un archivo y eliminar un archivo. Tenemos algunas APIs de consola rudimentarias, por lo que podemos hacer console.log y console.error, y tenemos una API básica de fetch, por lo que se parece a fetch, pero solo puede hacer solicitudes GET. Sin embargo, con solo 180 líneas de Rust y JavaScript, creo que esto es bastante fenomenal. Permítanme darles una demostración rápida del runtime run.js. Estoy en el repositorio que ya se les ha proporcionado y podemos ejecutar cargo run --example.ts. Por lo tanto, ejecutaremos un archivo TypeScript aquí y obtendremos hello run.js y también el contenido de fetch. Entonces, si decidimos inspeccionar nuestro archivo example.ts, podemos ver que usa console.log, luego tenemos una interfaz. Entonces

eso es definitivamente typescript. Y luego hacemos await run.js.fetches. También estamos usando await de nivel superior aquí. Y lamento por los ratones chirriantes, pero parece que mi configuración de VS code no lo entiende aquí. Muy bien. Así que vamos a adentrarnos en algunas cosas realmente interesantes. Entonces, ¿por qué querrías usar tu propio tiempo de ejecución de JavaScript? Hay algunos casos de uso. El primero de ellos es ejecutar código no confiable. Es posible que no nos creas al enviar Dno que es totalmente seguro ejecutar código no confiable. Por lo tanto, es posible que desees ejecutarlo dentro de ese contenedor. Sin embargo, ahora tienes un tiempo de ejecución de JavaScript y luego un contenedor. Por lo tanto, puedes esperar un poco de ralentización y utilización de recursos al hacer este doble envoltorio o doble aislamiento. Porque recuerda que V8, el motor de JavaScript, ya es un buen aislamiento. Por lo tanto, es posible que desees un conjunto limitado de APIs. Pero por otro lado, utilizarás muchos menos recursos, lo que nos lleva al segundo punto de que es posible que tengas limitaciones de recursos. Dno se envía con todo incluido. Tenemos muchas herramientas en la CLI, pero a veces ese binario puede ser demasiado pesado para ti, o es posible que no necesites todas las APIs que proporcionamos. Y proporcionamos muchas de ellas. Puedes interactuar con el sistema de archivos. Puedes hacer networking. Hay una gran implementación de varias APIs web. Pero si no las necesitas, tal vez puedas usar solo un subconjunto de ellas, lo que resulta en un binario más pequeño y más delgado. O por último, tal vez tu proyecto podría beneficiarse de enviar esencialmente un único binario autocontenido. Ya puedes hacer esto con Dino, pero a veces tal vez quieras personalizarlo un poco más o nuevamente, eliminar algo de la grasa que no se necesita en tu caso de uso particular. Aquí, te he proporcionado un enlace a un proyecto mío, un proyecto de sitio, donde intenté envolver ESLint en un archivo binario que utiliza las mismas tecnologías que vamos a utilizar en este ejemplo. Muy bien, así que vamos a hacer algo de programación. Vamos a hacer algo emocionante. Creo que podemos intentar implementar una API setTimeout en runJS. Por supuesto, esta no será la misma API setTimeout que se puede ver en los navegadores o en Dino o en Node.js, porque si bien esta API es realmente fácil de entender y usar, tiene muchas complejidades. Lo que quiero hacer es implementar setTimeout de una manera que tome una demora

en milisegundos. Tomará un callback y luego simplemente activará este callback. Pero omitiremos validation, asegurándonos de que todo se ajuste correctamente a WebIDL y demás. Muy bien. Así que pasemos directamente al código. Vuelvo a mi VS Code.

Entonces, comencemos eliminando este ejemplo e intentemos hacer setTimeout, y voy a hacer Esto lo haré más grande para ti. Haré hola mundo desde timeout. Y quiero que esto se active después de un segundo. Entonces, el retraso que pasamos es un milisegundo. Entonces, mil milisegundos es un segundo, y ahora, si intentamos ejecutar este código nuevamente, y déjame hacer esto más grande para ti nuevamente. Entonces, ejecutamos nuestro ejemplo.ts y obtuvimos un error de referencia. SetTimeout no está definido. Bueno, esto es esperado. SetTimeout no está integrado en el motor de JavaScript. En cambio, es una API web o una API integrada en Node.js. Pero no lo tenemos aquí. Necesitamos implementarlo nosotros mismos. Así que hagamos eso. Voy a entrar en el archivo Runtime.js, que es un archivo en el que implementamos todas las API disponibles en nuestro ejemplo Run.js. Entonces, como puedes ver aquí, estamos asignando a globaldisk.console un objeto console, que ups, no quiero ver la escritura, quiero ver el objeto real. Nuestro objeto console tiene las funciones log y error, y luego asignamos globaldisk.runjs con run.js, que contiene las cuatro API de las que ya hemos hablado. Así que agreguemos otra. Esta vez será globaldisk.settimeout. Y nuestro settimeout necesita aceptar dos parámetros. El primero es el callback y el segundo es el retraso en milisegundos. Entonces, ¿cómo lo vamos a hacer? Bueno, copilot se adelanta aquí, pero eso no es exactamente lo que haremos. Necesitamos llamar a Rust para hacer algo que espere el retraso dado, y solo cuando hayamos terminado de esperar, activaremos el callback. Entonces, comencemos agregando, llamando a car de async, y lo llamaremos offsetTimeout. Luego haremos delay como un

primer argumento. Eso parece razonable. Y luego queremos activar el callback. Entonces, sí, eso es prácticamente todo. Bien. Entonces, ¿qué sucederá si simplemente intentamos ejecutarlo ahora? Oh, no. Un error de tipo. Dice que el nombre de ops no es una función. Bueno, eso es esperado. Entonces, simplemente intentamos llamar a una función aleatoria de JavaScript, y se supone que esta función debe estar definida en Rust. Sin embargo, aún no hemos definido nada. Entonces, arreglémoslo ahora mismo. Solo voy a copiar el nombre de esta función y voy a ir al archivo main.rs. Este es el archivo que realmente implementa todo nuestro tiempo de ejecución. Como te dije antes,

todo este archivo tiene solo unas 140 líneas. Entonces, si nos desplazamos hacia arriba, podemos ver que tenemos una función asíncrona que es op write file. Luego tenemos op fetch, op remove file y op read file. Estas son las cuatro funciones que también se definieron en nuestro código de JavaScript runtime. Entonces, tienes read file aquí, write file aquí, remove file y fetch. Usemos solo una de ellas como ejemplo para proporcionar nuestro tiempo de espera opuesto. Voy a comenzar definiendo el atributo op. El atributo op proviene de Deno. Entonces, esto es algo que proporcionamos para ti. Nuestro tiempo de espera opuesto devolverá un resultado. Esto será simplemente identity, y luego devolverá cualquier error, pero realmente no necesitamos este error aquí, pero vamos a mantenerlo. Entonces, el valor de retorno será okay, y ahora hagamos la parte divertida. Necesitamos dormir de alguna manera durante el retraso dado, que aún no he pasado aquí. Entonces, obtenemos el retraso, que será U64, y ahora voy a aprovechar el fantástico ecosistema de fast grades para esperar de forma asíncrona el retraso dado. Entonces, voy a usar Tokyo para eso, que ya usamos en otra API. Entonces, voy a usar Tokyo, time, delay, sleep, y ahora necesito pasar una duración. La duración proviene de STD time duration, y ahora necesito crearla a partir de milisegundos. Claro. Ups, parece que mi IntelliSense está fallando. Entonces, vamos a dormir durante una duración tomada de la variable de retraso definida en milisegundos, y luego simplemente lo esperamos. ¿Será suficiente esto en realidad? Oh, claro. No necesitamos usar un signo de interrogación aquí. Entonces, lo definimos en JavaScript. Lo definimos en Rust. ¿Funcionará ahora? Probemos. Oh, no. Todavía no funciona. Bueno, aunque creamos esta función, realmente no le hemos dicho a nuestros genocrates que la usen, así que necesitamos registrarla aquí con nuestra extensión, y simplemente voy a decir OPSET TIMEOUT DECU, y ejecutarlo nuevamente. Ahí vamos. Acabamos de esperar un segundo y hemos impreso algo en la consola.

¡Eso es realmente impresionante! ¿Qué tenemos aquí? Una, dos, tres, cuatro, cinco, seis líneas de código RAST, y luego tenemos otras tres líneas de JavaScript. Así que sí, aquí tenemos SET TIMEOUT, una implementación muy básica de SET TIMEOUT que funciona. Volvamos directamente a la presentación. Sí, creamos un SET TIMEOUT mínimo. Creo que este conocimiento, aunque es muy básico y solo nos llevó unos minutos, debería ser suficiente para que puedas seguir agregando más APIs que puedas necesitar. Tal vez te gustaría crear un sistema de complementos para tu servidor de juegos y JavaScript. Puedes usar el crate de Deno como vimos en este ejemplo de run.js, y agregar más Ops para proporcionar el sistema de complementos. La cosa es que Deno, aunque es un runtime de JavaScript y TypeScript, también te brinda mucha infraestructura si quieres bajar a un nivel más bajo y hacer algo que se adapte realmente a tus necesidades, para que puedas usar la misma infraestructura que usamos para implementar APIs web, sistemas de archivos o redes, pero puedes elegir solo algunos de ellos que se ajusten a tus necesidades.

Y para ser honesto, las posibilidades de lo que puedes crear con esta infraestructura y escribir más por tu cuenta son simplemente infinitas. Aquí estás limitado por tu propia imaginación. Seguiremos haciendo estas publicaciones de blogs y grabaciones sobre cómo puedes crear tu propio runtime con más y más características en el futuro, así que mantente atento a la próxima parte. Y eso es todo de mi parte. Lamento que haya sido tan corto y que haya tenido que hacerlo rápido, pero espero que te haya parecido interesante. Todo el código fuente, las nueve líneas que hicimos aquí, estará disponible en este repositorio, así que por favor visítalo. Y nuevamente, si tienes alguna pregunta, estaré encantado de responder. Envíame un correo electrónico o envíame un mensaje directo en Twitter, y asegúrate de visitar nuestro sitio web. Gracias por tenerme aquí, y espero que hayas disfrutado esta charla. ¡Hasta la próxima vez!