Nunca te preocupes por CORS nuevamente

Gracias a todos. Sí, así que la API de renderizado no está lista todavía. Así que voy a dar una charla diferente sobre Bund. Algo así como... Primero voy a dar una pequeña descripción de qué es realmente Bund, y más o menos dónde nosotros... El pasado, presente y también el futuro de Bund. Donde Bund comenzó fue realmente frustrado con... Durante años he estado realmente frustrado con lo lento que es todo en las herramientas de JavaScript. ¿Por qué instalar tus paquetes a veces lleva minutos si estás en una gran empresa? ¿Por qué ejecutar la prueba lleva mucho tiempo? ¿Por qué cada comando se siente bastante lento, como cuando simplemente ejecutas un comando en tu terminal?

Y mucho de eso se debe a la complejidad de todo... Hay muchas capas en la pila, y si comprimes las capas, entonces obtienes menos cosas y el rendimiento mejora. Así que Bund es un runtime de JavaScript increíblemente rápido. Es realmente cuatro cosas en una. Es un runtime de JavaScript, es un gestor de paquetes, es un ejecutor de pruebas y es un empaquetador. Y cada una de estas piezas utiliza de alguna manera la otra pieza.

Así que, por ejemplo, el gestor de paquetes utiliza el mismo analizador JSON que utiliza el runtime, que también es utilizado por el empaquetador. El empaquetador en tiempo de ejecución, transpila cada archivo individual. Y eso utiliza las mismas cosas del empaquetador. Y este transpilador en Bund fue construido específicamente para Bund. No está utilizando ninguna biblioteca existente. Y el empaquetador también tiene soporte para cosas como React y CSS, así como TypeScript y JSX. También puedes compilar ejecutables de un solo archivo. Por ejemplo, Cloud Code, por ejemplo, utiliza esa característica. Pasamos mucho tiempo en la compatibilidad con Node.js.

Originalmente, Bund fue diseñado para ser un reemplazo directo de Node.js. Y lo que eso significa es que prácticamente todo necesita funcionar. Consideramos que es un error en Bund si algo funciona en Node y no funciona en Bund. Y si te encuentras con un problema como ese, por favor solo presenta un problema en el repositorio de Bund. Tenemos muchos problemas abiertos en GitHub, pero realmente los leemos todos. Solo que lleva mucho tiempo. Pero es importante.

Y hemos pasado mucho tiempo trabajando en que el conjunto de pruebas de Node pase en Bund, y todavía estamos trabajando en eso. Estos números están ligeramente desactualizados. Ahora hay un poco más de pruebas aprobadas. Así que hay otras partes de Bund también. Tenemos un gestor de paquetes npm increíblemente rápido. En la versión anterior de Bund, lo hicimos más rápido porque hay ciertos paquetes npm realmente comunes que no necesitan ejecutar scripts post-instalación o scripts de ciclo de vida, pero son como... O cuando necesitan ejecutarlos, la situación en la que necesitan ejecutarlos es muy limitada. Como si no usaras... O si omitieras dependencias opcionales. Así que hay muchos trucos que podemos hacer y seguimos haciendo para que la instalación de Bund sea realmente rápida. También añadimos recientemente soporte para la migración de pnpm lockfile. Escribimos todo un analizador YAML solo para eso, prácticamente. Y volviendo a lo que decía antes sobre las diferentes piezas de Bund... Usar las diferentes piezas de Bund, ese analizador YAML que escribimos para la migración de pnpm lockfile también es utilizado por el empaquetador, por lo que puedes importar archivos YAML en JavaScript en el runtime o en el empaquetador. Así que si estás construyendo para el front end, puedes importar el archivo YAML en tu código de front-end, y luego el empaquetador lo empaquetará en JavaScript.

Y luego, si lo estás importando en el runtime, entonces puedes simplemente ejecutar un archivo. Y esto es bastante bueno para cosas de configuración donde tal vez quieras cargar alguna configuración de acción o algo por el estilo. Bund test es un ejecutor de pruebas compatible con Jest. Utiliza la misma API de expect. Y también implementamos partes de las APIs específicas de VTest, como el global VI está ahí. Y añadimos muchas APIs integradas. Esto es algo que creo que ha estado faltando durante mucho tiempo en el ecosistema de JavaScript, que hay demasiados paquetes pequeños que hacen algo. Solo tienes que instalar tantas dependencias para ser productivo. Y no es necesario. De hecho, es más rápido si puedes hacerlo en el runtime, porque hay muchas optimizaciones que puedes hacer y, filosóficamente, tratamos de hacer cada parte de Bund realmente rápida. Y lleva mucho trabajo hacer eso. Pero hace que el producto sea mucho mejor. Y simplemente hace que sea mucho más rápido construir cosas también. Porque es como si pudieras usar la biblioteca estándar o la biblioteca integrada y esperar que sea rápida y funcione bastante bien. Así que, por ejemplo, Bund password es como Argon2 o bcrypt.

Puedes elegir cuál, que son como los algoritmos modernos de hashing de contraseñas. Tenemos un servidor WebSocket integrado con PubSub, lo cual es bastante bueno. Porque significa que puedes enviar el mismo mensaje a un grupo de conexiones al mismo tiempo. Y eso termina siendo también una mejora de rendimiento, porque puedes agrupar la sobrecarga para la cola del protocolo WebSocket.

Tenemos una API de glob de archivos integrada, tenemos un shell multiplataforma integrado. Es muy parecido a batch, así que generalmente, esto se hizo originalmente. Este es otro caso donde nos gusta reutilizar cosas en diferentes partes de Bund. Así que, para el gestor de paquetes en Windows, la gente frecuentemente tiene que instalar rimref, que es como rm-rf, pero como un paquete npm. Y así, con Bund shell, puedes simplemente usar rm-rf en tus scripts de package JSON, y funcionará en Windows, aunque Windows no soporte rm.

También tenemos un cliente Postgres integrado usando la sintaxis de plantilla de etiqueta SQL. También tenemos un cliente MySQL integrado, y básicamente tiene la misma sintaxis que el cliente Postgres. Puedes ver eso allí en la parte inferior. Simplemente cambias el protocolo, y decimos, oh, esto es MySQL. Conectémonos con MySQL en su lugar. Y esta es una muy buena manera de, como, hace que sea realmente fácil cambiar de proveedor de base de datos o usar cualquier adoptador de base de datos que desees. También tenemos un cliente Redis integrado, y Redis es como un almacén de clave-valor popular. Generalmente, la filosofía aquí es, como, estos son todos, como, Redis, MySQL, Postgres, S3, y los demás. Todos estos son, como, estándares muy antiguos, no antiguos, pero como estándares maduros que, como, hay software existente que, como, tratamos de no usar nada interno a medida que sea específico de BUN.

Como, y también todas las APIs están, como, basadas en algo existente. Así que, como, la interfaz de API real aquí es prácticamente la misma que Postgres.js. Este cliente Redis es mayormente similar a Ioredis. No es un mapeo al 100%, pero bastante cercano. Y eso también reduce el riesgo de esto, porque es como, está bien, parte del desafío, hay, como, qué APIs debería tener BUN, y luego también cómo deberían verse esas APIs. Y generalmente, lo que pasa con un runtime es que básicamente no puedes tener cambios incompatibles nunca, porque tampoco vale realmente la pena lidiar con cambios incompatibles desde, como, la perspectiva del usuario.

Así que es mucho menos arriesgado para nosotros si basamos cualquier API que añadamos en algún patrón común existente en el ecosistema, y nos esforzamos mucho por, como, no inventar cosas nuevas. Y luego optimizamos mucho de ello. Como, por ejemplo, el cliente Redis, cada vez que haces cualquier actividad de red en él, cualquiera de los comandos, no los envía inmediatamente. Utiliza lo que llamamos una cola de tareas diferidas. Básicamente, agrupa todas las llamadas de red para después de que se drenen todas las microtareas, pero antes del siguiente tick del bucle de eventos. Y eso significa que luego podemos combinar todas las llamadas de red para enviar a, que es la llamada al sistema que utiliza, automáticamente sin que el usuario tenga que hacer nada por sí mismo. Y eso lo hace mucho más rápido.

También tenemos una API de archivos integrada, button.file. Aún no tenemos una API de directorios, lo cual es un poco tonto. También tenemos una API de S3 integrada, y la API de S3 y la API de archivos son básicamente la misma cosa. Y eso es porque, como, S3 es generalmente lo que los servidores usan para producción, como, sistemas de archivos. Así que idealmente, la API del sistema de archivos remoto es prácticamente la misma que tu local. De esa manera es fácil probar entre los dos. También hace que sea realmente fácil, como, leer un archivo como JSON. Esto es algo tan común. Debería ser realmente fácil. También tenemos un montón de, como, no son aleatorios, pero básicamente, cuando hay un paquete que tiene decenas de millones o más de descargas semanales en npm, y son, como, realmente pequeños, con, como, un caso de uso muy claro que probablemente nunca va a desaparecer.

Como, por ejemplo, eliminando los colores para el terminal de NC, para escribir en el terminal. Así que este es el tipo de cosa donde podemos hacerlo mucho más rápido, principalmente usando SIMD, pero también implementándolo en código nativo. SIMD significa instrucción única, múltiples datos. Básicamente es un conjunto de instrucciones de CPU que permite a la CPU operar en más de un carácter byte a la vez. Así que en este caso, obtenemos una mejora de rendimiento de 10X, y tiene la misma, implementa la misma interfaz que el paquete strip-nc.

Similar a eso, tenemos la función button.stringwidth, que es un reemplazo de ancho de cadena 6,000 veces más rápido. Este no asigna ninguna memoria, por lo que podemos hacerlo 6,000 veces más rápido en lugar de solo 10 veces más rápido. Y para esto, se está utilizando algo de código del terminal Ghost-TTY. Y esto solo calcula cuál es el ancho de la cadena como el usuario lo ve en su terminal. Así que eso tiene en cuenta los grafemas, que son potencialmente caracteres no ASCII multibyte, o caracteres Unicode que a veces pueden combinarse.

Porque diferentes emojis... Esto va a convertirse en una tangente, dejaré de hablar. Así que esto es mucho de... Si solo miraras esto, dirías, está bien, ¿por qué añadiste todo esto? Porque todos estos son aparentemente aleatorios. Strip-nc, string-width, y file, y S3, y Redis, y MySQL, y password, y el servidor WebSockets. Todos estos son cosas completamente diferentes. Creo que en general, JavaScript simplemente no es lo suficientemente productivo hoy en día.

Otros ecosistemas de lenguajes son a menudo más productivos. Ruby on Rails tiene base de datos incorporada, tiene validaciones, tiene todas estas cosas donde mucho del tiempo y la programación se gastan. ¿Qué herramientas uso, y en qué cajas las pongo? Con React, usualmente todo es un componente de React. Con Rails, todo es un controlador, o está en algún lugar en el controlador, o en algún lugar en el modelo. Una gran parte de la razón por la que JavaScript no es lo suficientemente productivo es porque hay demasiados diferentes paquetes npm, tienes que pasar demasiado tiempo buscando bibliotecas. Si incluyes muchas cosas integradas, todo se vuelve más simple.

Otra cosa, también, es que el hardware, a lo largo de los años, se vuelve más rápido, pero nuestras computadoras realmente no se sienten mucho más rápidas, en general. La velocidad a la que el hardware se vuelve más rápido realmente no alcanza al software. Parte de eso es porque muchas de las mejoras de hardware son más visibles con cosas como Sim, donde la computadora es capaz de operar en más de un elemento o byte o lo que sea a la vez. En JavaScript, es difícil expresar eso. Así es como podemos obtener para el ancho de cadena, volviendo atrás, porque esto está usando Sims, por lo que puede hacer 64 caracteres a la vez o 32 caracteres a la vez, en lugar de operar sobre uno a la vez. Todo eso es genial.

Hace muchas cosas, pero creo que también es útil hablar sobre quién realmente usa BUN, porque aún no somos el entorno de ejecución de JavaScript número uno. Honestamente, es realmente emocionante. Estamos obteniendo mucho más uso en producción este año que en cualquier año anterior. Todavía somos relativamente nuevos. Todo el backend de Midjourney se ejecuta en BUN. Cloud Code usa BUN. Los Portland Trailblazers usan BUN para cosas de ciencia de datos, lo cual aprendí el otro día. Desde hace poco, puedes desplegar en producción el entorno de ejecución de BUN en Vercel. Datadog usa BUN en algunos de sus repositorios de código abierto. El DLI de CodeRabbit usa BUN. Desde hace poco, hay dos maneras fáciles de desplegar BUN. Puedes usar funciones de Vercel o puedes usar funciones de Railway.

Puedes usar funciones de Vercel o puedes usar funciones de Railway. Este es el runtime completo, por lo que puedes usar todos los frameworks que son específicos para BUN, así como todas las APIs de BUN. Pero todavía es un poco difícil desplegar BUN. Si estás construyendo una aplicación full-stack con BUN, entonces es muy difícil sentir que aquí están todas las partes que se preocupan por el frontend, aquí están todas las partes que se preocupan por el backend. Aquí está lo que debería ir en un CDN, aquí está lo que debería estar en mi servidor. Y esto es algo en lo que vamos a trabajar más pronto. Vamos a tener un subcomando de despliegue de BUN que generará este manifiesto y hará que sea realmente fácil desplegar BUN en otros proveedores de hosting, una variedad de diferentes proveedores de hosting.

También vamos a avanzar mucho más en la compatibilidad con Node.js. Va a ser un gran enfoque. Ya hemos avanzado mucho en esto, pero aún no hemos llegado. Y todavía hay cosas que surgen, como hay un playwright. Hay algunos problemas con eso que necesitamos solucionar de nuestro lado. Hay algunos problemas con los hilos de trabajo. Y hay muchas cosas así. Pero es mucho mejor de lo que solía ser. Esto también es algo en lo que he estado pensando mucho, que las cosas de IA se han vuelto realmente buenas. Era algo terrible hace dos años. Estaba bien hace seis meses, hace un año. Pero ahora puede escribir mucho código, por lo que probablemente significa que va a estar escribiendo mucho código en el futuro. Así que realmente no sé qué va a pasar allí, pero esto es algo que está en mi mente.

Y porque tenemos todo esto incorporado, lo que vemos es que muchos de nuestros usuarios simplemente eliminan un montón de dependencias cuando cambian a BUN. Así que está todo eso, pero entonces es como, ¿cómo uso realmente BUN? Bueno, la forma más fácil de usar BUN es simplemente cambiar setup node en tu acción de GitHub para que sea setup BUN. Y luego donde dice NPM o node, simplemente cámbialo a BUN. Por eso también tenemos BUN run, y luego también puedes ejecutar un archivo simplemente llamando a BUN. Es como, ¿debería ser como Node.js? ¿Debería ser como NPM? También puedes instalar BUN de esta manera. El script curl es generalmente lo que recomiendo, o el script de PowerShell, porque detectamos automáticamente si tu CPU es reciente o no, y luego elegimos la versión más rápida de BUN si tu CPU es relativamente reciente. Sí.

¿Alguna pregunta? La pregunta es, ¿BUN tiene soporte para clientes de NoSQL de forma nativa? No. ¿Es posible hacer eso? Creo que MongoDB probablemente es la cosa NoSQL más popular y es un poco difícil de ... Creo que MongoDB tiende a ser un objetivo en movimiento más rápido, por lo que no suele haber tantos clientes de terceros allí. También soy bastante reacio a añadir una cosa NoSQL aleatoria y menos popular, porque generalmente tenemos que soportar ... todo tiene que ser soportado básicamente para siempre, así que tiene que perdurar en el tiempo. Tiene sentido, ¿verdad? Porque SQL ha existido desde siempre, ¿verdad? Muchos de los motores SQL tienen una sintaxis bastante similar con algunas cosas diferentes, ¿verdad? Pero con NoSQL, hay tanto, ¿verdad? Genial.

Entonces, la siguiente pregunta es, ¿cuál es tu estrategia de versionado prevista para BUN frente a las versiones de Node, o planeas mantener el versionado de BUN más perenne? Creo que hay como dos preguntas ahí. Una es sobre BUN, SEMVIR o LTS, y luego la pregunta separada es cómo tratamos la versión de BUN, o qué versión de Node apunta BUN. Diría que generalmente nuestro plan aquí es que realmente no vamos a hacer SEMVIR, pero lo que vamos a hacer es versiones de configuración, donde cuando tengamos cambios importantes, entonces dices quiero la versión de BUN tal como se ve en esta versión. De esa manera, las personas pueden actualizar sin preocuparse por los cambios importantes. Claro, ¿verdad? Pueden descargar el último BUN, pero luego pueden apuntar a una API más antigua si lo necesitan. Sí. Genial.

Entonces, la siguiente pregunta es, ¿qué versión de BUN apunta para la compatibilidad con Node, si haces process.versions.node en BUN, mentirá y dirá la versión de Node que pretendemos ser. Esto realmente tiene que ser muy consistente porque muchas API de V8 C++ y como NAPI ambas esperan versiones muy específicas de Node, y como V8 y otras cosas. Así que en realidad es un montón de trabajo actualizar nuestra versión falsa de Node, porque también tenemos que actualizar nuestras vinculaciones de API de V8 C++ falsas y un montón de otras cosas. Entendido. Interesante. Entonces, ¿qué tan fácil es implementar BUN en un proyecto que ya tiene dependencias de NPM? Sí, realmente queremos ser un reemplazo directo para Node y también en muchos casos para NPM. Así que si ejecutas el archivo y no funciona, por favor presenta un problema en el repositorio de BUN. Básicamente, no deberías tener que hacer nada. Solo ejecuta el archivo.

Ok. Mencionaste que BUN tiene soporte para React. ¿Qué soporte es ese? ¿Y es ese el único framework de front-end soportado? Sí, tenemos soporte integrado para JSX, y luego simplemente se predetermina a React como los otros transpiladores de JSX. Así que lo que eso significa es que si estás usando React y tienes React instalado y quieres usar renderizado del lado del servidor de React, puedes usar las APIs de React para eso. No hay un estándar tan fuerte...JSX está algo estandarizado dentro de...hay una especificación de JSX y todo. Y puedes usar JSX sin React, y también puedes usar Preact de la misma manera que puedes usar React en BUN. Probablemente no vamos a añadir más frameworks de front-end como integrados en el transpilador, a menos que vayan a ser un poco... lo interesante de React y JSX es que la API del transpilador para ello es realmente estable. Generalmente, ha habido un cambio en los últimos... quiero decir 10 años, y eso es cuando cambiaron a la cosa nueva de la función JSX. Eso no es lo que se llama, pero básicamente es lo que es. Mientras que los otros frameworks de front-end son un objetivo que se mueve mucho más rápido, lo que hace difícil para BUN soportarlos. Correcto, pero aún puedes usarlos. Sí, tenemos un plugin de BUN para Svelte y probablemente haya uno para Vue también. Tenemos una API de transpilador que se parece mucho a la API de ESBuild, lo que significa que prácticamente cualquier cosa que use la API de plugin de ESBuild funciona con la API de plugin de BUN, y nuestra API realmente funciona tanto en tiempo de ejecución como en el empaquetador. Así que eso lo hace mucho más simple de usar en casos de servidor o cliente. Muy bien. ¿Cómo decides qué paquetes entran en BUN?

Es un poco arbitrario, para ser honesto. ¿Es esto lo suficientemente popular, y vemos una manera de hacerlo significativamente más rápido o algo por el estilo al hacerlo integrado? Y generalmente, ¿cuán complejo es? Por ejemplo, el de string-width, creo que fue un día y medio de trabajo, y luego es como, claro, tenemos que mantenerlo en el futuro, pero ese tipo de cosas son realmente de muy bajo mantenimiento porque el código realmente no cambia de vez en cuando. Tal vez cada cinco años tengamos que actualizar el grafema, los rangos específicos de puntos de código Unicode que usa, pero eso es bastante inusual. Sí, tiene sentido. Mencionaste que tomaste eso de Ghosty, lo cual es genial porque el tuyo está escrito en ZIG y el de ellos también, así que hay mucha portabilidad ahí, ¿verdad? Sí, sí. Muy bien. Entonces, has hablado sobre por qué deberíamos usar BUN.

¿Hay casos extremos donde no recomendarías BUN para producción? Generalmente, ahora mismo, los hilos de trabajo son bastante inestables. Usar trabajadores es estable, pero terminar trabajadores no es estable. Así que esa es una razón. Hay un puñado de complementos nativos, que aún no soportamos, que dependen de la API de C++ de V8. La mayoría de los paquetes hoy en día dependen de la API de Na'vi, para la cual tenemos muy buen soporte. Ejecutamos el conjunto de pruebas de Node para eso en cada commit. Pero sí, supongo que si estás usando hilos de trabajo y necesitas cerrar esos trabajadores o terminar esos trabajadores, entonces probablemente no uses BUN todavía.

Tal vez espera un poco. De acuerdo, tiene sentido. ¿Es el futuro de la comunidad de BUN extensible, o todas las características serán proporcionadas a través de desarrollos internos? Recibimos una serie de PRs de la comunidad. Puedes ver nuestras pull requests. Y generalmente diría que intentamos ser parte del ecosistema existente de JavaScript tanto como sea posible. No estamos tratando de ser separados. Por eso intentamos tener compatibilidad directa con Node.js. Por eso puedes simplemente ejecutar cosas que podrías ejecutar en Node. A menudo puedes simplemente ejecutarlo en BUN sin ningún cambio. Nos esforzamos mucho para que ese sea el caso, porque simplemente no vale la pena el tiempo reescribir nuestro código. Eso solo desperdicia colectivamente mucho tiempo, y eso simplemente no es necesario. Correcto.

¿Cuál es el siguiente aquí? Entonces, con BUN teniendo un enfoque tan fuerte en la velocidad y el rendimiento, ¿tienes algún consejo sobre evaluación comparativa que te gustaría compartir? Generalmente, quieres evaluar lo más cerca posible de tu uso en producción. Una cosa que puede ser bastante complicada es el JIT. Porque hay una trampa en la que muchas personas caen con la microevaluación de funciones pequeñas, donde el JIT ve que algunos datos son estáticos y luego hace algo que normalmente no haría en producción. Porque es realmente inteligente, y es como un perfilador en tiempo de ejecución, básicamente. Así que quieres perfilar tanto como puedas lo más cerca posible de la producción. Sí, eso es algo que he visto suceder mucho. De acuerdo, y solo para todos allá afuera, el JIT es el compilador just-in-time en los tiempos de ejecución. Entonces, ¿cómo maneja BUN las vulnerabilidades de seguridad? Sí, entonces nuestro proceso allí es que alguien nos envía un correo electrónico, o divulgan una vulnerabilidad a través de GitHub, y luego lo primero que hacemos es intentar reproducirla. Y luego intentamos solucionarlo rápidamente. De acuerdo. Entonces, incluso los zero days, ¿simplemente hacen un issue para eso o algo? No, hay una cosa en GitHub. Oh, ¿hay un proceso? No sabía eso. Sí, y es privado hasta que se publica. Oh, muy genial. Oh, sí. Es genial. Simplemente intentamos solucionar las cosas muy rápidamente tan pronto como podemos reproducirlas. Genial.

¿Y puedo usar BUN con cosas como Next.js? Sí. De hecho, en nuestro video de BUN 1.3, conseguimos que Lee Robb dijera en el video que podrías usar BUN con Next.js. Lee Robb es el ex devrel en Purcell. Así que sí, funciona muy bien. Y ejecutamos pruebas de Next.js en cada BUN comprometido para asegurarnos de que funcione bien. Así que háznoslo saber si encuentras algún problema y lo solucionaremos. Genial.

Y eso parece ser la última de nuestras preguntas. Y estamos justo a tiempo. Así que perfecto. Gracias por esas preguntas. Y siéntete libre. Vamos a pasar a nuestro próximo orador en un momento.