¿Es Bun 'Realmente' Más Rápido?

Así que de nuevo, bienvenidos a React Advanced London, y están aquí con Devlin Dudula. Ese soy yo, y he preparado algo para ustedes. Se trata de bun. ¿Es bun realmente más rápido?

OK. Así que para darles un poco de información sobre mí, una visión general, actualmente estoy basado en Oslo, Noruega, viviendo aquí desde hace cinco años, originalmente de Manila, Filipinas. Y durante la pandemia, como no puedo ir a casa, decidí pasar mi tiempo escribiendo libros y luego coautoré algunos.

Y la agenda de hoy sería ¿qué es bun? Características de bun, como gestor de paquetes, corredor de pruebas, empaquetador, tiempo de ejecución. Vamos a hacer un benchmark, ¿verdad? Pero tienen que tomarlo con un grano de sal. Voy a explicar por qué un poco más tarde. Y luego habrá una demo en el camino. Luego puntos clave. ¿OK?

Va a darnos una mejor experiencia para desarrolladores, mejor DX, en resumen. Vamos a disfrutar del desarrollo. El CI será más rápido. {{^}}Va a ejecutarse rápido, nos ahorra dinero. Y si un bundler es eficiente en disminuir el tamaño del archivo de la aplicación, va a tener menor tiempo de descarga o menos datos para tus usuarios. Eso ahorra dinero, ¿verdad? Pero en realidad, el impacto directo de esto en el medio ambiente es que ralentiza el calentamiento global porque tienes menos electricidad que consumir o menos computadoras que consumir. Porque todo es rápido.

Entonces, ¿por qué los creadores de bun eligieron construirlo sobre Zig? Así que Jared, el autor, dijo principalmente por su legibilidad y la naturaleza fácil de entender del lenguaje de programación, lo que le ayuda a escribir un código de rendimiento. Aquí hay un ejemplo de código de Zig. Digamos que quieres crear una función que calcule el cuadrado de un número. Pero en lugar de hacerlo mientras tu programa se ejecuta, quieres averiguarlo antes de que tu programa incluso comience. Y con este comp time, puedes decirle a Zig que calcule el cuadrado de un número cuando el programa se compila, y no cuando se está ejecutando. Esto significa que tu programa ya conoce el resultado antes de que incluso comience, haciendo tu código más rápido y eficiente. Así que al construir bun sobre Zig, los creadores han tomado la decisión de priorizar el rendimiento, la estabilidad y la compatibilidad. Y eso es exactamente lo que obtenemos con bun, un runtime moderno de JavaScript construido para la velocidad y facilidad de uso.

¿Cómo instalar bun? Puedes instalar bun ejecutando el comando npm install dash g bun. Alternativamente, puedes descargar el binario desde el sitio web oficial y seguir las instrucciones de instalación. Ahora vamos a sumergirnos en sus potentes características. Así que bun es más que solo un runtime de JavaScript. Es un kit de herramientas de desarrollo integral que incluye un gestor de paquetes, bundler, corredor de pruebas y runtime. Echemos un vistazo más de cerca al gestor de paquetes de bun. Si vas al sitio web de bun, puedes ver el resultado de su benchmark. Y por supuesto, como mejor práctica, deberías tener una validación sobre esto, o necesitamos encontrar evidencia de cómo hacen esto. Así que el gestor de paquetes de bun está diseñado para ser más rápido y más eficiente que estas alternativas. Esa es su opinión, mientras sigue proporcionando el mismo nivel de funcionalidad y compatibilidad. Las herramientas de benchmarking no son simples cuando estás, por ejemplo, midiendo qué tan rápido es una herramienta. Por eso la mayoría de las veces, no confiamos en el benchmarking porque las características incompletas de las herramientas lo afectan. Algunos autores priorizan una característica sobre la otra, y luego van a estar desajustados si estás usando diferentes herramientas porque algunas tienen características, estas características específicas, algunas no. Diferentes formas de usar también scripts, bibliotecas, frameworks, va a ser específico. Usando diferentes flags, tienen diferentes flags, ¿verdad? Diferentes máquinas también lo afectan.

Usando diferentes flags, tienen diferentes flags, ¿verdad? Diferentes máquinas también lo afectan. Entonces, ya sabes, el benchmarking podría ser inútil. Pero estamos aquí para aprender cómo puedes ejecutar algunos comandos CLI para benchmarking, y lo que necesitas saber. Aquí está cómo puedes hacer benchmarking por tu cuenta usando Hyperfine con algunas flags. Puedes instalar esto con tu Mac, Linux, o Windows con WSL2. Y aquí, vamos a comparar yarn, la versión 4, tienes PNPM, NPM, y luego bund.

Así que básicamente, esto es preparar aquí, esta flag preparar significa que vas a ejecutar un comando antes de que ejecutemos esta instalación. Por ejemplo, eliminando node modules. Calentar significa que vas a ejecutarlo una vez para obtener caché y usar caché. Y luego esto corre aquí, dash runs, significa cuántas veces quieres que esto se ejecute. Como, por ejemplo, 10 o 3. Y esto va a tomar, como puedes ver aquí, lo que significa que habrá como 10 yarn install, 10 PNPM install, 10 NPM install, etcétera. Y solo obtendrá el promedio de ello. Pero puedes usar solo uno si quieres hacerlo realmente rápido. Voy a hacer una demo aquí. Y de hecho, ya lo he ejecutado. Como puedes ver, bond, NPM, NPM, aquí están cuánto tiempo tomó para que NPM lo completara, bond, NPM, yarn. Y luego tienes este resumen. Normalmente, el que será el ganador aquí arriba y luego comparándolo con el resto. Por ejemplo aquí, bond, uno. Así que dice aquí bond install se ejecuta 3.73 veces más rápido que yarn, 3.8 veces más rápido que NPM, y luego 4.93 veces más rápido que NPM. ¿Qué son estas bibliotecas? Así que esto es solo aquí, una aplicación JavaScript de tamaño medio.

Así es como lo vas a hacer. Y esto será de hecho, este repo es público. Lo verás más tarde. Y puedes verificar y copiar cosas aquí. Y luego puse todo aquí como cómo empezar con hyperfine, qué herramientas necesitas, qué debería estar instalado en tu máquina. Así que bond, es rápido. Pero ¿cuáles son las cosas que podemos hacer con este gestor de paquetes? Solo te mostraré algunas cosas del gestor de paquetes de bond. Tienes este bond install, add, remove, update, link.

Tienes este caché global, workspaces, scripts de ciclo de vida, overrides y resolutions. Así que estos son solo comandos comunes que encontrarás en un gestor de paquetes.

Ahora pasemos a la parte del test runner de bond. Voy a usar nuevamente hyperfine. Y vamos a probarlo contra vtest y jest. Puedes ver aquí hyperfine, y hacer calentamiento y ejecutarlos tres veces cada uno. Así que eso sería para pruebas. Como puedes ver aquí, y tenemos un archivo readme para que veas lo que necesitas primero. Podrías necesitar typings aquí, por cierto. Así que no te dará errores de tipo script. Así que y estos son solo el mismo código. La diferencia es cómo los importas. Porque, por ejemplo, en vtest, necesitamos importar desde vtest. Lo llamo apple, así que sería como desde vtest. Lo llamo apple, así que sería como es fácil de ejecutar y distinguir. Así que eso será para vtest, el apple. Bond para banana aquí. Así que vas a importarlo. Básicamente la misma prueba. Orange sería para el jest. Y solo vas a ejecutarlo. Y aquí, nuevamente, calentamiento con hyperfine. Solo voy a esperar. Y primero se ejecutaría vtest. Segundo sería bond test. Y luego último sería jest aquí. Y tenemos el resumen nuevamente, lo que significa que ya está hecho, terminado y dice aquí bond test banana. Así que sabemos bond test. Luego dice aquí, tenemos esto 37.77 veces más rápido que vtest y 56.44 más rápido que jest.

Pero, ¿qué pasa con este 3.49 y 3.86? Estos son márgenes de error que si lo haces 3.49 veces más, veces más, los datos podrían ser diferentes con el tiempo. Así que esto es solo una cifra que puede dar resultados diferentes cada vez que ejecutas estas pruebas. Así que eso sería para la parte del test runner de bond. Volvamos a las diapositivas. Así que puedes hacer un montón de cosas con bond como test runner. Es rápido y tiene un test runner compatible con jest incorporado y las pruebas se ejecutan con el runtime de bond y soporta estas características. Sabes, escribir pruebas, usa lo que has aprendido de jest. Las pruebas se escriben en JavaScript o TypeScript con una API similar a jest. Puedes describir, probar, async. También puedes tener la bandera de watch para ejecutar pruebas. Hooks de ciclo de vida como antes de cada, después de cada. Puedes hacer configuraciones y desmontajes que quieras antes de todo, antes de cada, después de cada, y después de todo. Crear mocks con la función mock. Se ve así.

Y ahora para la parte del bundler. Los bundlers también ayudan en características del framework. Los bundlers habilitan características específicas del framework como el enrutamiento del sistema de archivos, colocación de código y componentes del servidor a través de plugins y transformaciones de código. En resumen, el bundling es esencial para una carga eficiente, compatibilidad de código y funcionalidad del framework en aplicaciones JavaScript modernas. Aquí, tienen su propio benchmark, ya sabes, agrupando 10 copias de 3.js desde cero con mapas de origen y minificación. Y este va a ser el nuestro. Voy a usar hyperfine de nuevo. Hemos preparado eliminando algo de caché. Y esto será como parcel, roll up, ES build, bun, RS build, y luego webpack usando webpack-cli. Y hay tantas cosas aquí porque necesito ser explícito con qué carpeta se generará la salida o el dist. Así que, volvamos a nuestro IDE, nuestro VS code. Va a estar aquí. Y todo, de nuevo, te dará algunos detalles de cuál instalar. Como parcel, roll up, ES build, bun, RS build, luego webpack. Luego ejecutando esto. Hyperfine.

Pero de nuevo, lo siento. Antes de que lo ejecutemos, solo voy a mostrarte qué tipo de código hay aquí en este main.js. Es solo Fibonacci. Muy simple. De nuevo, por eso es difícil confiar en los benchmarks, podría depender de quién está haciendo o escribiendo el código. Pero estoy aquí de nuevo para enseñarte qué herramientas necesitarías, qué recordar, y lo vamos a ejecutar.

Así que, solo voy a generar dos directorios aquí, el dist y out, porque diferentes bundlers usan diferentes nombres de directorio. Luego lo voy a mover aquí para que puedas ver. Parcel está hecho, roll up está hecho, ES build está hecho, bun está hecho, RS build está hecho, webpack está hecho. Dice aquí, bun, main.js. De nuevo, bun es un ganador aquí y dice que se ejecuta 1.00 veces más rápido que ES build. Es casi lo mismo. 10.60 veces más rápido que roll up. 36.63 veces más rápido que RS build. 40 veces más rápido que parcel y luego 100 veces más rápido que webpack. Bien.

Así que, veamos qué diferentes soportes podemos obtener de bun de forma predeterminada. Esto es usando CLI o usando JavaScript. Así. Y para los loaders, estos son loaders predeterminados tanto para bonding como también durante el runtime. Puedes escribir tu propio plugin. Por ejemplo, algo que haga extracción de CSS, macros y colocación de código cliente-servidor. ¿Verdad? Y en programación, tanto el comp time de Zig como el sistema de macros de Bun están diseñados para realizar cálculos en tiempo de compilación en lugar de en tiempo de ejecución. Sin embargo, operan en diferentes contextos y se utilizan en entornos de programación muy diferentes. Aquí hay una función simple que devuelve un número aleatorio. Y luego, sabes, aquí tienes que considerar que las macros se indican usando la sintaxis de atributo de importación. Si no has visto esta sintaxis antes, es una propuesta de TC39 de etapa 3 que te permite adjuntar metadatos adicionales a las declaraciones de importación. Y no verás el código de la función aleatoria en la salida del bundle porque se ejecutó durante el bonding. Puedo hacer una demostración aquí muy rápido.

Sobre estas macros de las que estoy hablando. Entonces, tenemos mat random. Y tienes esta consola aquí, ¿verdad? Y luego tengo aquí también de nuevo lo que run. Va a output. Y como puedes ver, comparándolo con una función export random que devuelve mat random. Va a main. Puedes verlo aquí, ¿verdad? Va a main. Puedes verlo aquí, ¿verdad? El problema es, creo que esto es pesado. Todavía está incluido aquí. Lo que vamos a hacer es incluir esta macro type. Mira aquí. Y luego tienes que cambiar algo en tu archivo TS config module. Sí, siguiente. Vamos a subir y buscar el módulo. Vamos a subir y buscar el módulo. Regresa aquí. Luego ejecútalo de nuevo. Así que, solo voy a optimizarlo para ti una vez que lo tengas. Bien.

Creo que se nos está acabando el tiempo. Así que, tiempo de ejecución. Entonces, para la parte de tiempo de ejecución de Bonn, Bonn usa el motor JavaScript core desarrollado por Apple para Safari, que supera a V8, y en la mayoría de los casos, además, es un runtime transpiler construido con Zig, resultando en tiempos de inicio cuatro veces más rápidos en Linux comparado con Node.js. Y hay algunas cosas que puedes hacer en el runtime de Bonn. Puedes ejecutar TypeScript, archivos SX directamente, Bonn procesa automáticamente tus archivos ENV, no necesitas ninguna biblioteca, como .env y mucho más. No tenemos una demostración aquí para el tiempo de ejecución, pero aún puedes ir al repositorio público de esta demo y ver las instrucciones allí, cómo puedes hacerlo. Preparé algo allí, pero desafortunadamente, no tenemos tiempo aquí.

Así que, puntos clave. Reduce el uso de CPU y la integración continua. Instalar dependencias de node es rápido, ejecutar pruebas es rápido, y bonding es rápido. Y recursos aquí. Ve al sitio web de Bonn y ZigLang. Y si también quieres usar un framework de JavaScript usando el runtime de Bonn, puedes ir a liciajs.com y esta demo aquí, todo este benchmarking. Y, sí, gracias por escuchar Bonn y cosas simples que puedes hacer para benchmarking. Eso es todo. Paz.