00:00:00(música animada) - Hola a todos.
00:00:06Soy Lydia.
00:00:07Mi título es en realidad Jefa de Propaganda en BUN.
00:00:11Y si me conoces un poco,
00:00:13sabes que me encanta hablar de runtimes de JavaScript y rendimiento.
00:00:17Antes de unirme a BUN,
00:00:18estuve en Vercel durante un par de años enseñando a desarrolladores de Next cómo construir aplicaciones más rápido.
00:00:24Así que estoy muy emocionada de estar aquí hoy y mostrarles cuánto mejor puede ser cuando combinamos el rendimiento de Next Framework con el rendimiento del runtime de BUN.
00:00:35Pero antes de hablar sobre BUN en sí,
00:00:37quiero retroceder un poco y mostrarles qué es lo que hace que frameworks como Next.js sean tan especiales en primer lugar.
00:00:45Porque realmente redefinieron cómo vemos el rendimiento en la web.
00:00:49No solo hizo que los sitios web fueran más rápidos.
00:00:52Simplificó cada parte del proceso.
00:00:55Tenemos bundling más inteligente con Webpack y ahora con Turbo Pack.
00:00:59Tenemos optimización de imágenes y fuentes integrada.
00:01:02Tenemos renderizado eficiente del lado del servidor,
00:01:05renderizado estático y ahora tenemos ISR y supongo que RSC para traer la obtención de datos al componente mismo.
00:01:12Y todas estas mejoras empujaron lo que el framework puede optimizar,
00:01:17pero realmente solo hasta cierto punto.
00:01:21Siempre ha habido una capa fundamental que Next.js aún no ha podido optimizar.
00:01:26Y esto no es por falta de esfuerzo de ingeniería o capacidad,
00:01:30sino que simplemente está fuera del alcance de Next.
00:01:34Y eso es el runtime en sí.
00:01:37Normalmente cuando ejecutas Next dev o despliegas a Vercel,
00:01:40tu aplicación Next se ejecuta en Node.
00:01:42Esto significa que el runtime de Node ejecuta tu JavaScript.
00:01:45Gestiona el bucle de eventos,
00:01:47entrada/salida de archivos,
00:01:48todo.
00:01:49Y conecta tu código JavaScript al sistema operativo.
00:01:53Y esto tiene sentido porque Node ha sido el runtime predeterminado durante aproximadamente los últimos 15 años.
00:01:59Ha sido probado en batalla,
00:02:01es confiable,
00:02:01pero en 2025,
00:02:02también se ha convertido en un poco un cuello de botella.
00:02:06No me malinterpretes, Node es fantástico.
00:02:09Hizo posible ejecutar JavaScript en el servidor.
00:02:13Antes de eso,
00:02:14antes de que Node se introdujera en 2009,
00:02:17JavaScript era realmente solo para el navegador.
00:02:20Node cambió eso dándonos un runtime con un motor de JavaScript,
00:02:23un bucle de eventos,
00:02:24async IO e APIs para hacer todas las cosas que los navegadores no pueden hacer.
00:02:29Como leer archivos del disco, memoria, todo eso.
00:02:33Ahora, bajo el capó, Node usa el motor de JavaScript V8.
00:02:37Este es el rápido motor Chrome de Google,
00:02:39que es excelente para tareas de larga duración,
00:02:42como una pestaña en tu navegador Chrome.
00:02:44Pero por supuesto, V8 es solo un motor.
00:02:46Solo sabe cómo ejecutar JavaScript.
00:02:49No puede abrir archivos,
00:02:51hacer conexiones TCP,
00:02:53y ese tipo de cosas.
00:02:54Así es donde entran las APIs incorporadas de Node.
00:02:57Como FS, HTTP, NET, y así sucesivamente.
00:03:01Así que estas APIs son como el puente entre nuestro código JavaScript y el sistema operativo.
00:03:07Y estas APIs en sí se basan en una biblioteca C llamada libuv.
00:03:13Esto no está construido para el propio JavaScript.
00:03:16Es más como una abstracción genérica que Node usa para poder hacer cosas como entrada/salida de archivos,
00:03:23redes,
00:03:24y cosas así en todos estos diferentes sistemas operativos.
00:03:27Entonces,
00:03:28cuando llamamos a algo como fs.read file en nuestro código JavaScript,
00:03:31realmente solo estamos pedirle a la computadora,
00:03:34como,
00:03:34quiero leer este archivo del disco.
00:03:36Pero antes de que podamos llegar allí,
00:03:38primero tiene que pasar por V8,
00:03:40o como del código JavaScript a V8.
00:03:42Luego se pasa al binding C++ de Node.
00:03:46Esto luego llama a libuv,
00:03:47y esto ni siquiera menciona el trabajo de hilos y todo ese tipo de overhead.
00:03:52Y solo entonces libuv realmente hace la llamada del sistema a nuestro kernel para obtener este archivo del disco.
00:03:58Y mientras todo eso está sucediendo,
00:04:00tenemos el bucle de eventos que libuv usa para que el resto de nuestro código JavaScript pueda seguir ejecutándose y así sucesivamente.
00:04:06Y este modelo funciona bien.
00:04:08Todavía estamos usando Node, pero no es óptimo.
00:04:13Entonces,
00:04:13en 2009,
00:04:14nuevamente cuando Node fue introducido,
00:04:16nuestro hardware se veía muy diferente.
00:04:19Los servidores tal vez tenían como cuatro núcleos,
00:04:22memoria limitada,
00:04:23y el almacenamiento era bastante lento.
00:04:25Los hilos también eran costosos,
00:04:27así que crear un nuevo hilo para cada conexión simplemente no escalaba bien.
00:04:32Así que el modelo de Node era excelente para esa era porque podíamos usar un hilo para manejar como miles de conexiones realmente eficientemente.
00:04:40Pero avanzando a 2025, nuestro hardware se ve muy diferente.
00:04:44Ahora tenemos cientos de núcleos de CPU,
00:04:46terabytes de memoria,
00:04:48y el almacenamiento es como 50 veces más rápido.
00:04:51Pero todavía estamos usando el modelo de Node basado en 2009.
00:04:55Todavía está empujando todo a través del mismo bucle de eventos.
00:04:59Y de nuevo, esto está bien.
00:05:00La arquitectura de Node está bien cuando los servidores corrían durante días.
00:05:04Pero en tiempos modernos,
00:05:05a menudo tenemos funciones serverless o tenemos servidores de desarrollo.
00:05:09Todos estos scripts más como ráfagas cortas que necesitan comenzar rápido y ejecutarse por mucho menos tiempo.
00:05:16Así que en estos entornos,
00:05:18cada milisegundo de inicio y cada capa de datos importa aquí porque todos suman a la latencia.
00:05:24Ahora de nuevo,
00:05:26cuando ejecutas tu aplicación next,
00:05:30la estás ejecutando en Node.
00:05:34Esto significa que todo lo que tu aplicación hace,
00:05:36como renderizar páginas,
00:05:38servir activos,
00:05:38transmitir respuestas,
00:05:40todo pasa por todas estas capas que acabamos de ver.
00:05:43Así que del JavaScript a VA a Node, todo ese tipo de cosas.
00:05:46Y Next ha hecho un trabajo increíble exprimiendo cada bit de rendimiento a pesar de que el runtime de Node todavía bloquea ciertas cosas.
00:05:57Porque al final del día,
00:05:58todas estas mejoras todavía se ejecutan en la parte superior de Node.
00:06:01Así que cuando configuras un servidor de desarrollo o reconstruyes archivos,
00:06:05recarga en caliente,
00:06:06todavía estás alcanzando esos límites de runtime.
00:06:09Así que si realmente queremos ir más rápido,
00:06:11tenemos que mirar más allá del framework.
00:06:13Tenemos que ir un nivel más profundo.
00:06:15Tenemos que repensar el runtime en sí.
00:06:18Así es donde entra BUN.
00:06:20BUN no es solo como otra capa construida en la parte superior de Node.
00:06:24Es un runtime completamente nuevo construido desde cero para el hardware que realmente tenemos en 2025.
00:06:33Así que en lugar de estar escrito en C++ en la parte superior de LibUV como viste con Node,
00:06:38BUN está construido en Zig.
00:06:40Y este es un lenguaje de sistemas moderno que se ejecuta mucho más cerca del metal.
00:06:45Así que para el motor de JavaScript,
00:06:47BUN usa el motor realmente rápido JavaScript Core de Apple.
00:06:51Y este se inicia realmente rápido,
00:06:53principalmente porque puede diferir algunas de las optimizaciones de inicialización que hacen motores como V8.
00:06:59Y también se ejecuta muy rápidamente,
00:07:01que de nuevo,
00:07:02es perfecto para las tareas modernas que usamos hoy en día con servidores de desarrollo,
00:07:07entornos serverless,
00:07:08y estos scripts de compilación más cortos.
00:07:10El runtime central en sí está escrito en Zig.
00:07:13Así que las APIs de BUN y todas las partes que manejan async I/O.
00:07:17Así que donde Node usa LibUV para todas estas operaciones async,
00:07:22como leer archivos,
00:07:23solicitudes de red,
00:07:24y así sucesivamente,
00:07:26BUN puede implementar estas como llamadas directas del sistema al sistema operativo porque está escrito en Zig.
00:07:33Ahora para solicitudes de red,
00:07:35usamos sockets de uso,
00:07:36así que es un poco diferente.
00:07:37Pero estamos eliminando tantas capas de abstracción usando Zig en lugar de LibUV.
00:07:44Así que ahora si quieres leer un archivo con el runtime de BUN,
00:07:47todavía va,
00:07:48por supuesto,
00:07:48desde tu código JavaScript.
00:07:49Ahora va al motor JSC a Zig,
00:07:51que puede hacer la llamada directa del sistema.
00:07:55Así que de nuevo,
00:07:56menos capas entre nuestro código JavaScript y el sistema operativo real.
00:08:01Y el resultado aquí es que todo se siente mucho más rápido desde el inicio hasta el acceso a archivos,
00:08:07servidores HTTP,
00:08:08y así sucesivamente.
00:08:09Pero BUN no es solo sobre rendimiento.
00:08:12También tenemos como objetivo ser 100% compatible con Node.
00:08:15Así que queremos asegurarnos de que todas las propias APIs de Node funcionen.
00:08:19Pero luego también se envía con toneladas de APIs incorporadas adicionales,
00:08:23como S3,
00:08:24SQL,
00:08:24o Squeel,
00:08:25lo que sea que quieras decir.
00:08:27Redis, hashing, un shell, tantas cosas.
00:08:30Y si alguna vez has usado otros lenguajes de programación,
00:08:33como Go o Python,
00:08:34este tipo de enfoque de baterías incluidas es muy familiar para ti.
00:08:39Pero como desarrolladores de JavaScript,
00:08:41simplemente nos hemos acostumbrado a instalar dependencias para casi todo.
00:08:45Uso hashing de contraseña en casi todas mis aplicaciones.
00:08:48Pero todavía tengo que instalar una dependencia cada vez que la uso.
00:08:52Así que BUN cambia eso.
00:08:54Las cosas que usas prácticamente todo el tiempo están simplemente integradas en el runtime en sí.
00:08:59Solo está construido en el global.
00:09:01Y de nuevo,
00:09:01estos no son solo como envolturas de nivel de superficie en la parte superior de una dependencia NPM.
00:09:06Están verdaderamente construidos en Zig.
00:09:08Así que están optimizados para el rendimiento del hardware moderno.
00:09:12Así que por ejemplo, BUN tiene un cliente SQL incorporado.
00:09:16Así que puedes conectarte directamente a Postgres,
00:09:20MySQL,
00:09:21y SQLite usando una única API.
00:09:23No tienes que instalar ninguna dependencia adicional.
00:09:26Y de nuevo, esto no es solo llamar a algún paquete NPM.
00:09:30Es verdaderamente todo BUN solo hablando directamente con el sistema.
00:09:35Y no es solo por conveniencia que tenemos estos integrados.
00:09:38Las opciones de BUN son generalmente también mucho más rápidas que las alternativas de Node y NPM.
00:09:44Así que por ejemplo aquí,
00:09:45BUN.SQL es hasta 11 veces más rápido que MySQL 2 en Node,
00:09:49lo cual es realmente bueno.
00:09:51O puedes usar el cliente S3 de BUN.
00:09:54Y esto funciona fuera de la caja con cualquier almacenamiento compatible con S3.
00:09:58Así que Amazon S3,
00:09:59Super Base Storage,
00:10:01Cloudflare R2,
00:10:02lo que sea.
00:10:03Y de nuevo, esta API también es increíblemente rápida.
00:10:06Así que aquí,
00:10:07podemos ver que es hasta como seis veces más rápido que AWS S3 SDK en Node.
00:10:12Ahora por supuesto,
00:10:13todavía puedes usar tus dependencias normales con el runtime de BUN también.
00:10:17No tienes que usar estas APIs incorporadas.
00:10:20Pero sí reducen tu tamaño de paquete mucho,
00:10:22porque ya no estamos agregando estas dependencias.
00:10:25Y ayuda con las vulnerabilidades de NPM que vimos el mes pasado,
00:10:30porque no tienes que instalarlas.
00:10:32Hay muchas más APIs.
00:10:33Recomiendo altamente que revises la documentación también.
00:10:37Pero BUN viene con mucho más que solo un runtime.
00:10:40También se envía con un gestor de paquetes realmente rápido que es hasta 17 veces más rápido que YARN,
00:10:47siete veces más rápido que NPM,
00:10:49y cuatro veces más rápido que PNPM.
00:10:51Y lo bueno es que no tienes que usar el runtime de BUN para usar BUN install.
00:10:55Y esto es solo -- puedes usar BUN install con Node.
00:10:58Simplemente funcionará.
00:10:59Así que no tienes que cambiar nada de tu proyecto.
00:11:03También tiene un bundler y transpilador integrados realmente rápidos.
00:11:06Así que puedes servir y construir tus archivos instantáneamente.
00:11:09Así que no necesitas Webpack,
00:11:10ESBuild,
00:11:11ninguna configuración adicional.
00:11:12Y lo bueno es que también soporta TypeScript y JSX directamente fuera de la caja.
00:11:18También tiene un ejecutor de pruebas realmente rápido que es hasta 14 veces más rápido que vTest y 23 veces más rápido que jest cuando renderizamos unas 1.000 pruebas de React.
00:11:26Así que de nuevo, obtienes pruebas muy rápidas.
00:11:29No tienes que instalar nada.
00:11:31Así que todo esto suena genial,
00:11:33pero ¿cómo podemos usar el runtime de BUN?
00:11:35Y Next, honestamente, es muy simple.
00:11:38Después de instalar BUN,
00:11:39solo tienes que actualizar tu comando start o tu comando dev y agregar bun run --bun.
00:11:45Eso es.
00:11:46Ahora estás ejecutando el runtime de BUN.
00:11:48Ahora te podrías estar preguntando,
00:11:50¿por qué necesito ese --bun?
00:11:51Como, ya estoy diciendo bun run.
00:11:54Eso es,
00:11:54de nuevo,
00:11:55porque BUN realmente se preocupa por la compatibilidad con node.
00:11:57Así que normalmente,
00:11:59si solo usamos bun run next dev,
00:12:02BUN detectará que el CLI de next usa ese shebang de node.
00:12:07Y en ese caso,
00:12:07BUN será como,
00:12:08OK,
00:12:09entiendo que tengo que usar node.
00:12:11Así que entonces simplemente volverá por defecto a node,
00:12:14aunque dijimos bun run.
00:12:15Pero con la bandera --bun,
00:12:17estamos forzando que se omita el shebang y digamos,
00:12:19OK,
00:12:20solo estamos usando el runtime de bun.
00:12:21Así que solo como una explicación adicional.
00:12:25Así que ahora con este comando,
00:12:27bun inicia tu servidor de desarrollo next.
00:12:29El bundler en sí aún es next.
00:12:31Así que eso es, ya sabes, Turbo Pack.
00:12:33Supongo que Web Pack,
00:12:34Turbo Pack,
00:12:34ahora es el predeterminado.
00:12:35Pero ahora el runtime debajo de todo eso,
00:12:37así que la cosa que está ejecutando tu JavaScript,
00:12:40leyendo archivos,
00:12:41sirviendo respuestas,
00:12:42y así sucesivamente,
00:12:43eso es todo bun.
00:12:44Y porque bun está diseñado para ser compatible con node,
00:12:47no deberías tener que cambiar nada de tu código.
00:12:50O tus paquetes o tu middleware.
00:12:51Todo debería seguir funcionando.
00:12:53Si no es así, eso también se considera un bug en bun.
00:12:57Debería ser 100% compatible con node.
00:12:59Así que si estás probando esto,
00:13:00te encuentras con problemas,
00:13:02háznos saber.
00:13:02Pero no deberías tener que reescribir nada.
00:13:05Y ahora que tu aplicación se ejecuta en la parte superior de bun,
00:13:08obtienes acceso a todas las APIs incorporadas de bun.
00:13:10Así que por ejemplo,
00:13:11podemos usar el cliente S3,
00:13:12¿verdad?,
00:13:12en como una función del servidor,
00:13:14en componente del servidor React,
00:13:15y así sucesivamente.
00:13:16Así que no tenemos que instalar ninguna dependencia.
00:13:18Así que solo para comparar lo que normalmente habría parecido con esto con node,
00:13:23puedes ver que con bun,
00:13:24tenemos mucho menos código.
00:13:25Tenemos menos dependencias.
00:13:27Y es instantáneamente compatible con todos los otros proveedores de S3 también.
00:13:32Así que si quieres cambiar de Amazon S3 a como Cloudflare R2,
00:13:35almacenamiento de super base,
00:13:37todos estos otros proveedores,
00:13:39eso es muy simple.
00:13:40O uno más completo,
00:13:41podemos usar S3,
00:13:42el shell de bun,
00:13:44y SQL directamente en un componente del servidor React.
00:13:47Así que primero,
00:13:48como consultamos la base de datos con SQL para obtener una publicación de blog,
00:13:52generamos una URL de S3 presignada para la imagen,
00:13:54usamos el shell de bun para contar las palabras.
00:13:57De nuevo,
00:13:57no hay una capa de API extra o herramientas de terceros que bun esté llamando.
00:14:02Bun maneja el runtime,
00:14:03las conexiones de la base de datos,
00:14:06y el shell nativamente en SIG,
00:14:08así de cerca del metal.
00:14:10Y de nuevo, por supuesto, no es solo S3 SQL.
00:14:12Obtenemos acceso a todas las APIs de bun solo agregando bun run --bun frente a next dev.
00:14:20Pero por supuesto,
00:14:21ahora podrías estar pensando,
00:14:22OK,
00:14:23no estoy usando Postgres.
00:14:24No estoy usando S3.
00:14:25No estoy usando ninguna dependencia loca,
00:14:27así que ¿por qué debería importarme?
00:14:28Lo que me enganchó a bun antes de unirme fue honestamente solo la increíble experiencia del desarrollador.
00:14:34Puedes simplemente ejecutar cualquier archivo JS,
00:14:37TS,
00:14:38TSX,
00:14:38JSX,
00:14:39no importa sin ninguna configuración.
00:14:41Simplemente funciona.
00:14:41No tienes que pensar en TSNode,
00:14:44Babel,
00:14:44SWC,
00:14:45y así sucesivamente.
00:14:46Así que incluso si no estás usando next,
00:14:48incluso si solo estás desarrollando,
00:14:51quieres un script de compilación rápido,
00:14:53solo usando bun run,
00:14:54simplemente intenta,
00:14:55hace tu vida mucho mejor porque no necesitas ninguna configuración.
00:14:59Bun también viene con bun x.
00:15:01Y esto es el equivalente de bun a NPX.
00:15:04De nuevo, no tienes que cambiar nada.
00:15:06No tienes que usar el runtime de bun para esto.
00:15:08Solo puedes cambiar NPX con bun x.
00:15:11Y ves mejoras de inicio instantáneamente.
00:15:13Así que por ejemplo,
00:15:15usando bun x create next step es como cinco veces más rápido que NPX create next step.
00:15:20Y de nuevo, no tienes que usar el runtime de bun para esto.
00:15:23Es solo mucho más rápido.
00:15:25Pero por supuesto,
00:15:26también está bun install,
00:15:28que de nuevo,
00:15:28no requiere que cambies el runtime.
00:15:31Solo hace que tus instalaciones sean mucho más rápidas,
00:15:34también en proyectos básicos de next.
00:15:36Ahora obviamente, ejecutar bun localmente es una cosa.
00:15:39Pero ¿cómo desplegamos aplicaciones que se ejecutan en bun?
00:15:42Porque esto es,
00:15:43por supuesto,
00:15:44un runtime completamente nuevo.
00:15:46Ahora ya puedes usar Next.js en bun en varias plataformas como render,
00:15:51railway,
00:15:51o containerizar tu aplicación con Docker.
00:15:54Pero todos somos desarrolladores de Next.js.
00:15:56Idealmente, también queremos poder desplegar a Vercel.
00:16:00Así que naturalmente,
00:16:02tuiteamos a Guillermo,
00:16:03pidiéndole amablemente soporte nativo de bun en Vercel.
00:16:07Y rápidamente obtuvimos una respuesta bastante prometedora.
00:16:10Y luego un par de semanas después,
00:16:12el soporte de bun se ha logrado al menos internamente.
00:16:15Así que estoy muy emocionada de que el soporte nativo de bun llegará a Vercel muy,
00:16:20muy pronto.
00:16:20Y esto significa que podrás -- [APLAUSOS]
00:16:25Los aplausos van a los grandes ingenieros de Vercel que hicieron esto posible.
00:16:29Pero esto es muy emocionante porque significa que ahora podemos ejecutar aplicaciones de bun tan fácil como cualquier otro proyecto de Next en Vercel.
00:16:37Así que también solo un ejemplo del mundo real.
00:16:39No estoy segura si puedes verlo en la pantalla.
00:16:41Pero ejecutar una API HONO con bun ya vio una caída del 30% o una caída de CPU simplemente ejecutando bun en Vercel.
00:16:49Esto es, por supuesto, un framework diferente.
00:16:50Este es HONO API.
00:16:52Pero son los mismos beneficios de runtime que obtendrás si esto fuera como una función del servidor,
00:16:56RSC,
00:16:57y así sucesivamente.
00:16:57Porque bun ahorra mucho en uso de CPU y memoria.
00:17:02Ahora no tenemos que esperar al soporte nativo de bun para empezar a usarlo en nuestras aplicaciones,
00:17:05por supuesto.
00:17:06La forma más simple es tipo empezar a usarlo o adoptarlo incrementalmente.
00:17:11Así que primero,
00:17:12recomiendo simplemente cambiar a bun install.
00:17:14No cambia nada en tu base de código.
00:17:16Esto solo usa el gestor de paquetes realmente rápido de bun.
00:17:19Además,
00:17:19si estás interesado en saber por qué bun install es mucho más rápido,
00:17:22escribí un artículo sobre esto hace poco.
00:17:24Recomiendo altamente que lo revises.
00:17:26Solo explica -- ya sabes, no estamos saltándonos pasos.
00:17:29Estamos haciendo lo que sea.
00:17:29Tipo explica la ingeniería de sistemas detrás de ella que la hace mucho más rápida.
00:17:35Ahora después de usar bun install,
00:17:37luego intenta usar el runtime de bun.
00:17:39Puedes usarlo localmente con bun run --bun.
00:17:42Prueba tu aplicación.
00:17:42Ve si todo funciona.
00:17:44Debería.
00:17:45Si no, háznos saber.
00:17:47Y luego finalmente,
00:17:48puedes tipo incrementalmente moverte a las APIs nativas de bun donde tenga sentido.
00:17:53Por supuesto,
00:17:54todavía puedes mezclar y combinar estas dependencias de NPM.
00:17:57Pero la mejor parte es también que cada paso aquí es reversible.
00:18:00Así que si usaste una de las APIs nativas de bun y no funcionó,
00:18:03siempre puedes simplemente cambiar de vuelta a node.
00:18:06Pero definitivamente vale la pena ver.
00:18:08Ahora antes de terminar esta charla,
00:18:10solo quiero dar un agradecimiento muy grande al equipo increíble de ingenieros en bun.
00:18:17La mayoría de las personas podrían conocer a Jared,
00:18:19pero hay un equipo completo detrás de bun que trabaja tan duro cada día para hacer bun aún más rápido,
00:18:24más estable,
00:18:25y mucho más divertido de usar.
00:18:27Realmente están empujando los límites de lo que es posible con JavaScript.
00:18:32Así que Next,
00:18:33reimaginó cómo construimos para la web,
00:18:35pero bun reimagina qué la impulsa.
00:18:38Muchas gracias por venir a mi charla,
00:18:40y estoy tan emocionada de ver qué construirás con bun y Next.