Construyendo aplicaciones Full Stack React con Bun

Gracias a todos. A lo largo de los años, las herramientas de JavaScript se volvieron demasiado lentas y complicadas. Nuestra respuesta a eso es Bun. Bun es un runtime de JavaScript increíblemente rápido. En cada commit, ejecutamos más de 2,000 pruebas del conjunto de pruebas de Node.js. Diseñamos Bun desde el principio para ser un reemplazo directo para Node.js. Todavía estamos trabajando en eso. En eso es en lo que la mayoría del equipo pasa la mayor parte de su tiempo, en la compatibilidad con Node.js.

Pero está mejorando básicamente cada día. El porcentaje total está aumentando aproximadamente un 1 por ciento cada semana o así del conjunto de pruebas de Node.js pasando en Bun. Bun también es un gestor de paquetes. Es realmente rápido. Mucha gente ha dicho que si puedes RM-RF Node modules, eso es más lento que instalar paquetes con Bun install. Para hacer eso, hicimos mucho trabajo en cuál es la forma más rápida de copiar archivos en cada plataforma objetivo, y también, a veces, como el sistema de archivos.

Bun test es un ejecutor de pruebas compatible con jest realmente rápido. Puedes usarlo con JSX, TSX, todo eso está integrado. Puedes importar y requerir en el mismo archivo. Esta es la comparación. Es 20 veces más rápido que jest para SSR, 1,000 componentes de React, pero luego solo para imprimir el menú de ayuda, es tres o cuatro veces más rápido. Esto es como, Bun es cuatro cosas diferentes en una. Es un gestor de paquetes, es un empaquetador, es un runtime, es un ejecutor de pruebas. Tenemos la intención de reemplazar gran parte de la cadena de herramientas con una herramienta simple.

Cada una de estas cosas funciona en conjunto, así que, por ejemplo, el runtime utiliza el empaquetador. El ejecutor de pruebas también utiliza el empaquetador y el transpiler. El runtime utiliza el gestor de paquetes para instalar automáticamente paquetes. Si no lo haces, tienes una carpeta de Node modules. El gestor de paquetes utiliza el shell para tener scripts de shell multiplataforma, de modo que tus scripts JSON empaquetados con comandos como RM o CD o LS o cualquiera de esos comandos simplemente funcionen, ya sea en Windows o Postix, de modo que no necesites instalar RimRath, por ejemplo. Y hemos incorporado muchas APIs. Esta lista va a crecer. Todavía hay mucho más que queremos hacer. Tenemos un servidor WebSocket, tenemos un cliente S3, tenemos un cliente Postgres, tenemos hashing y verificación de contraseñas. Se pueden construir muchas aplicaciones sin dependencias. Y también está el empaquetador.

Hoy en día, el empaquetador de Bun tiene soporte rápido para React integrado. Tiene un analizador de CSS. También tiene un analizador de HTML con re-escritor de HTML. También tenemos tree-shaking, un minificador, code-splitting. Una característica un poco menos común que tenemos, o menos común en comparación con otros empaquetadores es que puedes hacer echo de console.log desde el navegador al terminal. Esto es realmente útil para agentes de IA donde normalmente no pueden depurar cosas en tu navegador muy fácilmente. Normalmente necesitas instalar alguna cosa MCP, pero simplemente hicimos que console.log transmita al navegador sobre la misma conexión WebSocket que hace para HMR. También tenemos plugins que esperarías. Puedes usarlo con Tailwind y Svelte.

¿Cómo construyes una aplicación React full-stack cuando la mayoría de lo que acabo de describir está muy enfocado en el front-end o el back-end, pero, para un full-stack, necesitas tanto el front-end como el back-end juntos? En la próxima versión de Bun, puedes simplemente importar HTML, y eso funciona tanto por adelantado como en desarrollo. Así es como se ve hoy. Hay rutas en bun.serve. Especificas dónde quieres que se renderice el archivo HTML, y luego también puedes tener rutas de API allí también. Así que entonces estás ejecutando tu aplicación React en desarrollo, o potencialmente en producción de esta manera. Y puedes ver que las rutas también soportan parámetros de solicitud. Esto sería para un acortador de URL. Utiliza APIs de solicitud y respuesta, los estándares web. Y puedes ver que casi no hay configuración aquí. Eso es todo lo que tenías que hacer.

Así es como se ve el HTML. Entonces, lo que está sucediendo aquí es que está construyendo el front-end y el back-end al mismo tiempo con bun build, y lo hará por adelantado. De esa manera, no necesitas ejecutar el empaquetador en tu servidor de producción porque eso es un poco tonto. Entonces, lo que eso significa es que con bun build ahora, puedes tener bajo demanda, puedes hacer que la construcción ocurra bajo demanda en desarrollo, y luego en producción, lo haces por adelantado. Así es como debería funcionar. Parece bastante obvio que así es como debería funcionar, y simplemente no lo hacía antes, porque todo lleva tiempo. Así que eso es bun. Estamos haciendo JavaScript más simple. Gracias. Gracias.

La primera pregunta es, ¿por qué es bun mucho más rápido al descargar paquetes? ¿No es la velocidad de la red el único factor limitante? Así que esto es un poco sorprendente, pero no es el único factor limitante. Hay muchas cosas que tienen que suceder para instalar paquetes. Tienes que extraer archivos tar, tienes que asegurarte de que también tienes que analizar un montón de JSON. Al principio, cuando estaba perfilando, en las versiones iniciales, cuando estaba como, ok, ¿cómo hacemos realmente un gestor de paquetes que sea realmente rápido? Noté que mucho tiempo en los gestores de paquetes actuales se gastaba analizando JSON. Uno de los trucos que hacemos es que cuando descargamos el manifiesto de NPM, lo serializamos en un formato binario, verificamos si ese manifiesto coincide con el manifiesto del servidor, y cuando lo deserializamos, es efectivamente una copia de memoria, lo que significa que hace muy poco trabajo cuando deserializa los datos reales. Así que básicamente bun no pasa mucho tiempo analizando JSON, o se esfuerza mucho por no pasar tiempo analizando JSON cuando no es estrictamente necesario. Y luego también hay muchas cosas con llamadas al sistema. Pasamos mucho tiempo en cuál es la forma más rápida posible de copiar archivos, cuál es la forma más rápida de, y también cómo usar el menor número de llamadas al sistema. Sí, eso tiene sentido.

Aquí hay otra. Runtime, empaquetador, gestor de paquetes, pruebas, son problemas difíciles de resolver. Otras herramientas típicamente se concentran en solo un problema. ¿Cómo puede bun mantener todo esto? Básicamente, las herramientas que elegimos construir en bun se usan mucho entre sí. Así que el runtime utiliza el transpiler, el ejecutor de pruebas utiliza el transpiler, el gestor de paquetes utiliza partes del transpiler también, incluso solo para el analizador de JSON. Así que parece que es un montón de cosas diferentes, y lo es, pero también todas esas cosas se reutilizan, así que terminamos, eso ahorra mucho trabajo. Sí. Alguien también dice que si bun es un reemplazo para todo, ¿por qué no se usa más ampliamente? Todavía somos bastante nuevos. Honestamente, creo que lo principal aquí es que todavía tenemos problemas con la compatibilidad con node, y por eso estamos trabajando tanto en ello. Y mi expectativa es que solucionemos la compatibilidad con node, pero también, hay un montón de empresas que usan bun en producción hoy en día.

Puedes ver que nuestro servidor de Discord tiene un montón de personas. Si buscas en Twitter, verás a muchas personas hablando sobre bun todo el tiempo. Paso demasiado tiempo en Twitter. Sí, en mi experiencia, bun es una de esas cosas que cuando lo usas, dices, oh, wow, esto es algo especial.

Siguiente. ¿Soporte de monorepo en bun? ¿Cuándo? Entonces, sí, admitimos monorepos, pero hay un montón de pequeños problemas que necesitamos solucionar y que aún no hemos solucionado. Recientemente solucionamos algunos de ellos. Añadimos soporte de catálogos similar a los catálogos de PNPM. Admitimos espacios de trabajo por sí mismos. Puedes usar la versión de espacio de trabajo en el especificador de dependencias en package.json. Puedes usar espacios de trabajo en general. No creo que la experiencia sea realmente buena todavía, siendo honesto.

Pero vamos a mejorarla mucho muy pronto. La conclusión es que vamos a añadir la carpeta de módulos de nodo de enlace simbólico al estilo PNPM, y la usaremos para espacios de trabajo, y luego usaremos nuestros módulos de nodo elevados existentes fuera de los espacios de trabajo. Creo que es un enfoque realmente bueno para reducir el número de paquetes duplicados y resolver mientras también se previenen los tipos de problemas con dependencias transitorias que obtienes con los módulos de nodo elevados. Genial.

Tenemos muchas preguntas llegando aquí. ¿Estás planeando trabajar con Tanner, TAN stack, Vercel, o el equipo de React router para integrar los frameworks y routers? Sí, queremos trabajar con todos. De hecho, tengo un PR para Next ahora mismo que tiene pruebas fallidas que necesitan arreglar para que puedas importar módulos integrados dentro de Next. Básicamente, una cosa complicada es que como Bund tiene algunos módulos integrados, los Bundlers no saben que estos existen, y no aparecen en node modules, así que se confunden. Así que básicamente, sí.

Sí. Dado el contexto de la última, bueno, no la última, pero la primera charla del día, ¿manejará Bund la ejecución del compilador de React? Quiero que lo haga. Hubo como un, esto fue hace como seis meses, intenté ver hasta dónde podía llegar Dalem portando la implementación incompleta en Rust del compilador de React, y totalmente no funcionó. Pero básicamente admitimos plugins de JavaScript en el Bundler y los haremos rápidos. Son como, bueno, todavía hay algunas cosas que podemos hacer allí. Pero funcionan. Podrías ejecutar el compilador de React hoy. Probablemente sería como un plugin de 100 líneas de código. Justo como JavaScript. Sí.

Sí. Bien, podemos hacer uno más aquí, porque tenemos muchas preguntas. Solo un recordatorio de que habrá una sesión de preguntas y respuestas afuera en el balcón también. Así que elijamos una buena aquí. Sí. ¿Qué tal, o no, me gusta bastante esta. ¿Estás trabajando con proveedores de nube para introducir el runtime de Bund? Queremos más. No creo que haya mucho que pueda decir. Sí. Esa es una buena respuesta. Muchas gracias, Jared.