This graph shows how many times the word ______ has been mentioned throughout the history of the program.
Mis pensamientos sobre BUN y otras aventuras.
Mateo Colina es uno de los más importantes desarrolladores
que está en el equipo de Core de Node.js, ¿vale?
Y es bastante interesante porque muchas cosas que dice
pues tiene un impacto tremendo en la comunidad
y ha dado su opinión justamente sobre BUN.
BUN es una alternativa de Node, de Webpack,
de compilador de TypeScript, Testing, de NPM,
un montón de cosas, ¿vale?
Pero ¿qué pasa?
Que dentro de todo este hype que se ha generado
ha habido bastante polémica por diferentes cosas, ¿no?
Una, de que si realmente era tan rápido como prometían.
Dos, si realmente nos podemos fiar de una empresa
que puede tener un impacto muy grande y es una empresa.
O sea, Node.js, que sepas que en realidad es de una fundación,
es de la OpenJS Foundation y no tiene ánimo de lucro,
pero BUN o BUN sí que tiene, ¿ok?
Entonces, a lo mejor van a intentar monetizar de alguna forma la idea.
Hay otro tema polémico que se está diciendo mucho,
que lo dice en palabras grandes aquí,
que es que dice, BUN dice que es compatible con Node.js, ¿vale?
De hecho, lo pone por aquí.
Dice, BUN es NPM Compatible Package Manager, ¿vale?
Dice, Node.js compatible.
Instala las dependencias en Node.js y tal.
O sea, dice que es totalmente compatible con Node.js,
que es retrocompatible, que no te tienes que preocupar,
que puedes importar todo.
Y es verdad que muchas cosas funcionan, pero hay otras que no.
De hecho, en su propia página de compatibilidad, que la tenéis aquí,
veis que pone BUN,
su objetivo es ser totalmente compatible con la API de Node.js.
Casi todos los paquetes de NPM que están pensados para Node.js
deberían funcionar sin ningún tipo de problema, ¿vale?
Y aquí podéis ver que hay algunos, por ejemplo, este está en rojo,
hay algunos que están en amarillos,
hay otros que están en verdes, que están totalmente...
O sea, que no está...
O sea, la compatibilidad no es al 100%, como podéis ver, ¿no?
Entonces, vamos con esto.
Este tema es importante.
¿Qué dice Mateo?
Dice, bueno, estoy escribiendo esto, estoy en un avión, ¿vale?
Que se va a Londres, que está trabajando en un sitio.
Y habla de BUN, ¿vale? 1.0.
Dice, estoy muy contento, pero a la vez estoy decepcionando.
Literalmente le gusta todo el trabajo que ha hecho Jared Sumner,
el creador de BUN.
Dice, pero estoy un poco frustrado por esto que dicen
de que realmente es compatible con Node.js.
En mi experiencia, no es un reemplazo que lo cambias y ya,
sino que hay detalles de dentro que cambian.
Y esto resulta en un montón de issues totalmente aleatorias.
Y hay un montón de repositorios donde me están pidiendo
que arregle incompatibilidades con BUN,
cuando realmente el problema no es mío, es de BUN, ¿no?
Y lo primero que ya habla, y esto viene a saco,
es, ¿por qué más rápido BUN que Node.js?
Y dice, primera razón, Node.js no tiene presupuesto.
Punto, ¿vale?
Somos un equipo pequeño que mantiene NPM.
Casi todas las inversiones es para añadir nuevas funcionalidades
o para hacerlo más seguro, no para hacerlas más rápidas.
Hacer las cosas más rápidas no le da dinero a nadie.
Es un poco una tragedia de lo común.
Más aún, los cloud providers no tienen ningún tipo de interés
en mejorar el rendimiento de nada,
porque significaría menos dinero para ellos.
Muy bestia.
Claro, esto depende.
Porque dice cloud providers y aquí tiene media razón.
Sí que tiene razón en que AWS, Amazon, Google, Microsoft,
le puede interesar esa parte,
pero en el caso de Vercell es todo lo contrario.
En el caso de Vercell, que en realidad lo que están haciendo
es revenderte el servicio de Amazon,
y también es un cloud provider,
le interesa todo lo contrario.
Lo que va a querer realmente es poder hacerlo más rápido
para consumir menos recursos,
para tener que pagar menos, pero a ti cobrarte lo mismo.
Y además te lo va a vender como menos tiempo.
Puede ser que a Amazon y tal le pueda interesar,
aunque yo también tengo mis dudas ahí,
pero bueno, yo creo que muchas veces cloud providers
pensamos que solo son tres y hay un montón.
Lo segundo, bond no se tiene que preocupar
por la retrocompatibilidad
con una porción significante del ecosistema de NPM.
Ellos hacen las cosas rápido
que preservan la retrocompatibilidad
como un hecho a posteriori.
Así es como tú te aproximas
a la construcción de software rápido.
En cambio, Node.js, como está construido,
es proteger el ecosistema en su lugar.
Nosotros sabemos cómo hacer Node.js más rápido,
pero esto va a crear,
crearía un montón de fricción en un montón de usuarios.
Tercero, creemos en los estándares abiertos
y en el gobierno, la gobernanza abierta.
Los entornos de ejecución y afructura son mejores.
Teniendo una gobernanza abierta
significa que la toma de decisiones
tienen que ser más amplias
y por lo tanto más lentas.
Tienes que hacer que todo el mundo sea escuchado.
Así que necesitan más tiempo para tomar decisiones.
Ahí podéis ver los tres puntos por los que dice
y la verdad es que me parece muy bien
porque sí que es verdad que veo que mucha gente no entiende
por qué realmente Bond es más rápido y ya está
y por qué Node.js no lo hacen más rápido y punto.
Y las cosas no son tan sencillas muchas veces.
Ahora, ¿por qué BAN actualmente no soporta Pino y Fastify?
Que al final muchas veces Pino y Fastify
son dos bibliotecas muy utilizadas en el ecosistema de Node.
Dice BAN no soporta Fastify o Pino.
Son dos módulos que tienen un impacto muy grande.
Pino siendo tan popular como Next.js.
El equipo, obviamente, de BAN van a añadirle
la API que falta, el comportamiento
y esperan ponerse al día en los siguientes meses.
Pero claro, eso no es algo que ellos podrían hacer.
Últimamente, BAN no implementa todas las APIs de Node
y entonces no puede ser un reemplazo de Node.js como dice.
Dice que BAN Install, que dice que va tan rápido,
viene también a un coste
y comenta que una de las cosas más impresionantes de BAN
es la performance de BAN Install.
Sin embargo, viene con un coste para el desarrollador.
Y es que BAN se va a quedar con la versión local al principio.
O sea, por defecto.
A mi opinión, la rapidez de Boom podía ser una trampa
para privatizar aún más la web.
Yo prefiero mil veces que sea más lente,
pero aún siga siendo 100% la comunidad.
Hombre, yo también prefiero que sea mil veces más lenta,
pero que sea de la comunidad.
Pero también queremos que no sea mil veces más lenta.
O sea, lo que ha pasado con BAN está bien.
Está bien entender esto porque a lo mejor si lo que queremos
es que Node.js vaya más rápido,
pues a lo mejor tenemos que donar dinero.
¿Sabes? Este tipo de cosas.
A lo mejor también eso es interesante que lo hagamos.
Que hay veces que creemos que queremos las cosas gratis
y a lo mejor pues tenemos que apoyar a Node.js,
por ejemplo, ¿sabes?
¿Y por qué Node.js no es capaz de conseguir financiamiento
como lo hacen otros proyectos o empresas?
Para que nos hagamos la idea.
Webpack ha recaudado en todo el tiempo que existe,
que ha recaudado de empresas.
Chrome, Tribago, Airbnb, Shopify, Vercell.
O sea, de todas las empresas, ¿vale?
¿Cuándo salió Webpack?
Webpack debe tener 10 años fácilmente.
2012, o sea, 11 años.
En 11 años ha recaudado un millón y medio.
En 11 años, ¿vale?
Lo que quiere decir que son unos 100.000 dólares,
160.000 dólares por año, ¿vale?
Oven ha conseguido, que es la empresa de BAN,
7 millones de dólares nada más empezar.
Que tiene un año, ¿entendéis?
O sea, la diferencia.
¿Entendéis la diferencia?
La diferencia es exagerada.
Esto lo ha hecho un tío
y lo que ha hecho el tío
es crear una empresa
y tener inversión y tal.
Esto tiene sus cosas buenas
y sus cosas malas.
Lo bueno, obviamente,
que va a conseguir 7 millones de dólares,
va a poder construir el producto que sueña.
Lo malo, pues que va a necesitar ser rentable.
Esto es lo bueno que vamos a tener de Node.js siempre,
que nunca va a buscar ser rentable.
Node.js, uno,
no va a tener unos intereses detrás
que las funcionalidades,
si va a funcionar un hosting o no
y todo esto,
no vas a tener nunca un problema.
Siempre va a ser abierto
y vas a escuchar a todo el mundo
y lo único que va a buscar
es lo mejor para el proyecto.
En cambio, en BAN,
lo que vamos a tener
es que siempre se va a buscar
que sea rentable.
¿Por qué?
Porque hay gente que ha puesto dinero
y lo que quiere es ver su dinero crecer.
Y esto puede ser bueno
porque vas a construir el proyecto
mucho más rápido
y también puede ser malo
porque los intereses de ganar dinero
se anteponen.
Claro, puede pasar eso.
Pueden empezar a cobrar
para recuperar el dinero
20 céntimos de dólar
por cada bin install,
micropagos
o que ciertas funcionalidades de BAN
solo funcionen en su hosting.
Me apuesta es que dentro de un poco de tiempo
nadie se acordará de BAN
y el equipo de Node.js
se pondrá a modo Berserker
mejorando la velocidad.
Yo creo que sí.
Yo voy a ser bastante optimista
y creo que sí que vamos a ver
mejoras de rendimiento
bastante importantes
en tema de Node.js.
No creo que vaya a llegar
al punto de BAN.
Es imposible
porque obviamente no puede llegar.
Pero yo creo que sí que vamos a ver
mejoras de rendimiento
y vamos a ver mejoras importantes
en general
de funcionalidades
y tal
que le faltan.
Starks
y tal