No sé si conocéis el que está llamado a matar a Node.js, el matador de Node.js le voy a llamar, el matador de Node.js.
No, pero en serio, está considerado uno de los frameworks, entornos de ejecución que más buena pinta tiene.
Y no estoy hablando de Dino, estoy hablando de BAN.
Pero ojo, porque pasó algo bastante importante y yo creo que no muy bueno de cara a BAN, un fail en todas reglas.
Si a mí me preguntan, a mí parece un fail bastante importante, así que os voy a explicar.
El 7 de septiembre se iba a lanzar BAN, ¿vale? Hicieron, fíjate, BAN 1.0 is here, claro.
Pero el tema es que no estuvo here. Esto ocurrió ayer, hace 22 horas, pero amigos, resulta que hace 22 horas no lo pudieron sacar.
No sacaron BAN 1.0. Bueno, vamos a ver un poco por encima la presentación.
Este es el creador, por si no lo conocíais, es Jared Palmer, que por cierto es un crack.
BAN 1.0 es final here.
No es final here, era mentira.
Ha hecho Jared Palmer y es Jared Sandmer.
Bueno, perdón, es Jared, sabía que se llamaba.
Está bien porque dijo, está finalmente aquí y no estaba aquí.
BAN es un toolkit completo para construir, ejecutar, testar y debugger JavaScript.
Se ponen aquí a hablar y a venderte y tal.
Está muy bien el vídeo, lo recomiendo un montón.
Sobre todo para que entendáis qué es BAN, por qué es importante, las cosas buenas que tiene.
Está muy, muy chulo.
Bueno, la mejor cosa que tiene la tenéis aquí, ¿vale?
Esto, por ejemplo, ¿qué pasa?
Que BAN también es un empaquetador de aplicaciones web.
O sea, es un compilador de TypeScript.
Súper rápido.
Es un entorno de ejecución como Node.js.
Es un empaquetador de aplicaciones web como lo es Sbuild, pero mucho más rápido.
Fijaos las comparativas.
Es una alternativa a NPM también.
O sea, es una salvajada.
Es increíble, ¿no?
Son muchas cosas, muchas cosas.
Y la verdad es que funciona y va muy, muy, muy rápido, ¿no?
Entonces, bueno, aquí estaban presentando.
También tiene soporte a JSX nativo, que esto es una cosa que también tenía Dino.
Tiene un montón de cosas que lo hacen que tiene muy buena pinta.
La velocidad, especialmente.
Bueno, fijaos.
Mensajes por segundo.
La comparativa con Node.js.
Es que lo destroza.
Lo destroza directamente.
Y, además, es retrocompatible con Node.
O sea, tú, los códigos que tengas de Node también funcionan con BAN.
No tienes que adaptar el código ni nada.
Funciona de una y ya está.
Mira, aquí tenéis, por ejemplo, la ejecución de test.
Imaginad.
Imaginad hacer una migración.
Mira vTest, que es increíblemente rápido, ¿vale?
VTest, que es 1,91 segundos.
Pues BAN tarda 0,23.
Tener esto en vuestro despliega producción, algo que ahora es tarde un segundo,
que tarde 10 segundos.
Imaginad esto.
¿No os parece como algo mágico pensar que puedes pasar a producción,
pasarle todos los test en 10 segundos?
O sea, sería increíble poder pasarle los test.
Seguro que os pasa algo en los test, que si tardan 2 minutos, 10 minutos, lo que sea, ¿no?
¿Por qué es tan rápido?
Son dos motivos por los que es tan rápido.
Lo primero es que BAN utiliza un lenguaje de programación que se llama ZIC,
que es más parecido a RAST, ¿vale?
Y esta es una razón por la que es más rápido.
Es un lenguaje de programación de propósito general que está pensado para ser óptimo, reusable, robusto,
y está muy, muy bien optimizado.
Entonces, utiliza ZIC.
También utiliza en algunas partes C++, pero en algunas que es lo mismo que utiliza Node,
pero el utilizar ZIC marca la diferencia.
Y hay otra diferencia también que es clave.
Y es que Node utiliza V8, el motor V8, que es el mismo que utiliza Chrome,
pero BAN no utiliza V8.
BAN utiliza en realidad JavaScript Core.
¿Y qué es esto de JavaScript Core?
JavaScript Core es el motor de JavaScript que utiliza Safari, que es el de Apple.
Y Safari, si una cosa tiene, es que va muy fino.
Va muy, muy, muy rápido.
Así que lo malo que tiene es que a lo mejor a JavaScript Core no le llegan tan rápido las novedades de JavaScript,
como sí que le suelen llegar a V8.
Pero la verdad es que hoy en día, como se están poniendo tanto las pilas, yo creo que no habría ningún problema.
Así que esas serían las dos razones.
Y hay una tercera razón que tampoco se habla mucho, pero es bastante interesante, ¿no?
Una cosa que tiene este hombre, el Jared, que es el creador, es que es un fricazo de la performance.
¿Qué quiere decir esto?
Por ejemplo, cuando tú quieres copiar un archivo, hay la forma obvia.
¿Cómo copiarías un archivo?
Pues, obviamente, lees el archivo y escribes el archivo.
Esa es la forma clásica, normal, natural, en la que la inmensa mayoría de la gente piensa esto, ¿vale?
Y esto, pues, lo hacen Node.js, lo hacen incluso el comando cp, el comando cp normal y corriente que tenéis aquí en las utilidades, ¿vale?
Este cp, este comando, es lo normal, es lo que haría cualquiera, ctrl-c, ctrl-v, efectivamente, ¿no?
Pues este hombre no hace leer el archivo, escribir el archivo.
En BAN, lo que están haciendo es una cosa totalmente diferente, mucho más compleja.
El tío se leyó un paper que te explicaba cuál era la forma más óptima de hacer una copia de archivos.
Y entonces, cómo hacía un mapa de bits, cómo transformaba mientras hacías streams de los datos,
para que mientras lo copiabas, lo transformabas y lo escribías, ¿vale?
Pero no solo hacer el streaming, sino que la transformación que hacías al vuelo,
para también comprimir el stream, para que tardase todavía menos.
O sea, el tío se hizo un pedazo de, se leyó un pedazo de estudio solo de cómo copiar archivos de forma óptima y eficiente.
Y es espectacular.
A ver si lo encuentro, porque creo que era un vídeo, Jared Sumner, BAN.
A ver, os lo voy a enseñar.
Ah, mira, mira, en este, este, este, este es.
Este vídeo está muy chulo, pero bastante, bastante que te huele a la cabeza.
¿Vale? Aquí el hombre, aparte de no peinarse, la madre que lo parió.
Pero claro, es que no me extraña, es que este hombre, pensad que esta persona, él solo, ahora ya no,
pero al principio, sobre todo, él solo, creó este todo en uno, que es mucho más rápido que Node, que un montón de cosas, ¿vale?
Pues en esta charla, os explica justamente esto.
Mira, aquí tenéis el ejemplo este que os comentaba del copy file.
Esto es Node, ¿y cuánto tiempo tarda en Node?
Que ya, estamos hablando de microsegundos, ¿eh?
Microsegundos. Bueno, aquí son 30 milisegundos, ¿vale?
30 milisegundos. Esto es con Node.
Y esto, y esto es con BAN.
¿Veis que pone 108? Que parece, que parece más.
Pero es que no. Es que fijaos que son microsegundos.
O sea, no sé si, ¿son micro o nano?
Ahí tengo la duda, si son micro o nano. Yo creo que es micro.
Vale, pues fijaos la diferencia. O sea, estos son 30 milisegundos.
Y esto, 108, o sea, es que es muchísimo, muchísimo más rápido.
Y aquí el tío, a ver si lo encuentro, a ver si lo encuentro, os explica cómo lo hace.
O sea, te dice, vale, esto, ¿por qué hace esto rápido? No sé qué.
Ah, esta frase, joder, es que esta charla es bastante interesante.
Dice, mira, mucha gente piensa que el final de la ley de Moore significa que el software no puede ir más rápido.
Pero esto no tiene sentido. El software de hoy en día raramente llega al límite de los límites teóricos del hardware.
Esto es totalmente cierto, que es brutal. O sea, es brutal porque muchas veces pensamos que es un tema de hardware,
pero en realidad es una falta de optimización en muchas de las cosas que tenemos.
¿Ves? Mira, ¿cuál es la forma más rápida de copiar un archivo?
Es que yo de vez en cuando... ¿Ves? La forma fácil, read wide.
Para que veáis que no me invento las cosas que voy diciendo, ¿vale?
Que no me invento. Vale, mira, aquí tenéis.
Clone file, FNTCL, el modo difícil.
Clonar en un rango, el send file, splice, e ir copiando por rango, ¿vale?
Entonces, este hombre, el tío lo comenta, ¿no?
De que como se lo estuvo mirando, que no sé qué, no sé cuánto.
Y lo mismo con hacer una codificación de UTF-16 a UTF-8.
Y aquí habla también de papers que ha leído al respecto.
Esta sería la forma fácil.
Y aquí dice, y entonces yo me he leído este paper, este artículo de investigación de cómo transcribir miles de millones de carácteres Unicode y no sé qué.
Y entonces, así es como he conseguido que no sé qué.
O sea, la verdad, muy chula, ¿eh?
Esta charla es un poco avanzada, pero solo por la flipada.
Bueno, aquí es muy corta, ¿eh? Son 10 minutos la charla, luego son preguntas.
Ahora empiezan las preguntas, empiezan a preguntarle y tal.
Este hombre es un crack, la verdad.
Es un verdadero salvaje y tiene todo mi respeto porque es muy, muy, muy crack.
Total, ¿qué ha pasado? ¿Cuál es el salseo?
El salseo es que ayer se anunció y se hizo esta presentación de BAN 1.0, ¿no?
BAN 1.0, se anunció, no sé qué.
Y te decían aquí, bueno, ya puedes instalar la versión 1.0 de no sé qué, no sé cuánto.
Venga, disfrútalo, todo perfecto.
Pero no, no, no se pudo disfrutar.
No se pudo disfrutar y vamos a ver por qué.
Hace 18 horas estamos arreglando un bug en el Body Streaming Defetch.
Esto es un blocker para lanzar la nueva release.
Tengo un fix, pero parece ser que no lo tiene, no es del todo con fetch específicamente.
Es uno de los bindings de JavaScript Core.
El fetch, el test manifestó que era un bug porque los tests se ejecutan mucho, no sé qué, no sé cuánto.
Total, que no pudieron, no pudieron desplegarlo a producción.
O sea, que no pudieron, aunque lo anunciaron y todo, no pudieron lanzar la versión 1.0.
Pero, de hecho, lo han anunciado, la han lanzado ahora mismo, ahora, justo mientras estamos haciendo directo, es que la han lanzado.
La tenéis aquí.
Boom 1.0 está aquí, léete el anuncio.
Ahora sí que es verdad que está, por fin, 8 de septiembre, ¿veis?
Ha sido hoy, no ayer, que es como lo tuvieron que hacer.
Sinceramente, a mí, o sea, me sabe muy mal porque sé que hay un trabajo titánico detrás, pero ha sido un fail, ¿eh?
Ha sido un fail por todo el hype que había, el tener una fecha, pero sabéis que es mala publicidad, la verdad es que sí.
Van a salir de esta, ¿eh? No pasa nada.
Creo que es traumático, pero no es, no es que diría que esto es como una mancha para siempre.
Pero lo que sí es verdad es que mi sensación, mi sensación que tengo es que Van va a cuchillo.
Si veis el trabajo de Van en el repositorio, alucináis, ¿eh? Alucináis mucho, mucho.
Mira, hace 16 minutos, pero es que lo veis desde ayer.
Fijaos, ¿eh? 8 de septiembre, no sé qué, aquí, pa, pa, pa.
Y es que hasta el último momento, hasta el último momento han estado trabajando incansablemente para llegar.
Ir a cuchillo, me encanta la expresión, ir a cuchillo significa ir a por todas.
Ir como para adelante, casi intentando no mirar nada a los lados, ¿no?
Y ir lo más rápido posible.
Y esto obviamente te puede pasar factura, porque tienes muchas cosas que abarcar.
Él lo iba diciendo, me falta todavía esto y faltan cuatro días y que no sé qué.
No se le había agobiado, pero sí que mi sensación era como, uff, ojo,
porque yo veo que van justitos, van justitos, ¿eh?
Esto los hace más humanos, si no, totalmente.
Mejor no sacarlo que sacarlo con bugs, eso total, ¿eh? Eso total.
Pero también es verdad que antes de sacarlo con bugs, yo creo que tendrían que haber sido bastante más,
haberse dado más tiempo de sacarlo más tranquilos, bien testeado,
porque esto es una cosa que, no sé, muchas veces, a ver, está mal verlo como mala publicidad.
Dice Raz, cancelaron su primera release para corregir un bug importante.
Eso habla muy bien de su responsabilidad.
No, no, a ver, a ver, dentro de lo malo han hecho bien,
pero es obvio que algo de mala publicidad le da, teniendo en cuenta,
es como, imagínate que Vercell anuncia NextGS 14 para el 14 de septiembre,
bueno, el 14 de octubre, ¿vale? Imagínate eso.
Y va el 14 de octubre, hacen el vídeo de presentación,
te han enviado, pues, invitaciones para ver el lanzamiento y tal,
y te dicen, bueno, chicos, no, lo lanzamos el día siguiente.
Obviamente has perdido el momentum, has perdido, tienes un poco, una mancha,
han hecho bien, han obrado bien, o sea, es mejor, demuestra que han sabido rectificar,
obviamente, totalmente, y bien por ellos.
Hay que darle la enhorabuena por el lanzamiento y por lo que están haciendo,
pero obviamente estoy convencido que no es lo que hubieran deseado,
y nosotros, ni ellos, ni nadie, obviamente.
A ver, hay gente aquí que dice, es open source y deberíamos estar agradecidos y tal.
A ver, tenéis razón, pero también no tenéis razón, ¿vale?
Y os voy a explicar por qué.
A mí me encanta Van, a mí es un proyecto que me encanta,
pero tenéis que tener en cuenta que Van es open source,
pero hay una empresa detrás, la empresa se llama Oven.sh,
y detrás de aquí, de esto, seguro que van a salir servicios para desplegar Van,
pensad, mira, está Guillermo Rauch, Guillermo, si lo puedo, mira, Guillermo,
Guillermo Rauch, es una empresa que ha levantado 7 millones de dólares.
A ver, que podemos estar de jiji, jaja, y os digo, Van, a mí me encanta como proyecto,
pero hay 7 millones de dólares de inversores que le han puesto, ¿sabes?
O sea, le han puesto ahí muchas esperanzas,
y obviamente esto no se habrá tomado bien, obviamente.
O sea, un inversor estaría esperando que todo fuese perfecto,
que no significa que la gente ahora tiene que ponerse a manos a cabeza,
que no se trata de eso,
pero que sí que fue, pues, un pequeño problemilla,
que por suerte lo han arreglado y ya está.
Han sacado la versión 1.0, ahora ya se supone que sí que es estable,
y no hay ningún problema, ya está.
O sea, me parece genial que al final han salido, que es lo importante.
Lo bueno es que ya lo tenéis, de hecho, lo podéis actualizar,
yo no lo he actualizado todavía, o sea que vamos a poner Van a Great,
y fíjate, ¿ves? Yo tenía la 0.8.1 y ya tengo la 1.0.
Pero sinceramente, yo le tengo muchas, pero muchas esperanzas a Van, ¿eh?
Yo apuesto mucho por Van, ¿eh?
Me gusta mucho el proyecto de Van porque creo que vamos a ver
muchas cosas que se van a mover a Van, porque es que es muy rápido.
Es rápido, como dice Karin, as fuck.
O sea, es muy rápido.
Mira, fijaos todo lo que quita Van, encima en una sola herramienta.
Tenéis Node, NPX, VanX es 5 veces más rápido que NPX.
Node.mon, no necesita Node.mon porque Van ya tiene un watch mode
que lo tenéis puesto.
No hace falta dote en Ficros.env porque también lee los archivos .env por defecto.
Que esta es una razón por la que Node se está poniendo también las pilas.
O sea, Node nos está ayudando Van a que Node vaya por todas.
Pero ojo, también Van, ¿qué hace?
Transpila el código.
No lo transpila, es que claro, tú puedes ejecutar código de TypeScript con Van.
No hace falta que hagáis nada.
O sea, vosotros, si hacemos aquí VanDemo, VanDemo, ¿vale?
Que esto también lo hace Dino, que sé que lo hace Dino, ¿eh?
Que ya sé que la gente mira, ah, es que esto lo hace Dino, que no sé qué.
Hola, ¿vale?
Si vais aquí Van y le ponéis Index.ts, ¿vale?
Fijaos que ya lo tenéis ahí.
Pero el tema es que no solo hace esto, también soporta JSX.
O sea, también podéis utilizar aquí JSX.
Por ejemplo, en Message y poner aquí H1, hola, H1.
¿Vale?
Esto lo transformáis en TSX y ya funciona.
El problema es que no tengo React, pero lo podemos instalar.
Mira, súper rápido.
VanInstall, React.
Y es que es increíblemente rápido.
Es increíble...
Hostia, ¿por qué se está instalando ahí?
Se está instalando un montón de cosas raras.
276...
273...
¿Sweep Adler?
¿What?
Estoy flipando ahora.
¿Por qué me he instalado una cosa totalmente distinta a lo que he dicho?
A ver, ha sido rápido, pero ha sido más lento porque me he instalado cosas que no le he dicho.
O sea, he hecho banInstall React y me he instalado otra cosa.
Y no, no tiene package.json.
No tiene package.json.
Es opcional.
Lo podemos crear, ¿eh?
Que funciona con el package.json también.
Vamos a poner aquí dependencies.
Vamos a poner React.
18.
React.dom.
Import.
Esto lo podemos quitar, ya no lo editamos.
Ah, bueno.
Import React from React.
¿Vale?
Y ahora hacemos pnpm install.
¿Vale?
Bueno, es que no tarda nada.
O sea, es exagerado.
Mira, vamos a quitar el new modules, ¿vale?
Hacemos aquí pnpm install.
Ay, pnpm install no.
BanInstall, perdón, ¿eh?
Que he hecho pnpm.
159 milisegundos con React y React.dom.
O sea, brutal, ¿eh?
Y fijaos aquí que ya tenéis esto.
Podríamos importar también React.dom.
Import React.dom.
From React.dom server.
¿Vale?
Y podríamos hacer aquí esto.
Hacer esto.
Esto.
Sé que hay una forma nueva de hacer esto, pero bueno.
Solo para que lo veamos que funciona.
Ban index.tsx.
¿Veis?
Para que veamos esto funcionando.
Hola number.
Oh, ¿qué ha pasado?
Number.
Solo hace referencia al tipo, pero aquí se usa.
Solo hace referencia.
Ay, coño, no es number, es A.
Me he equivocado, perdón.
¿Vale?
Pero veis, ya estamos con esto.
Ya estaría, ya podrías hacer, o sea, estaríamos utilizando React.
Sin ninguna transpilación ni nada.
Totalmente de forma nativa.
Está transformando, o sea, estamos utilizando TypeScript, TSX, JSX.
Esto te quita Babel, BabelRC, BabelPreset, TSNode, TSNode, TSX, todo eso te lo quita.
También te quita los bundlers.
No necesitas Sbuild, Webpack, Parcel, todo esto fuera.
¿Por qué?
Pues porque con ban, además, podríamos hacer, no sé si había un comando y tal.
¿Veis?
Build.
Pues le puedes decir, bundle TypeScript JavaScript into a single file.
O sea, puedes hacer ban build y le puedes decir que te haga una build del index.tsx.
Esto te lo pueden mandar al index.jsx.
Entonces, aquí, fijaos que ya lo tenemos todo compilado.
Todo compilado.
Y encima lo podéis también minificar, ¿vale?
Y ya lo tendríais minificado.
Pero fijaos, o sea, la rapidez que tiene.
O sea, aquí tenéis mi código.
El código que tengo aquí del render to sync, que lo podéis buscar.
¿Ves?
Está aquí.
Este es mi código.
Me lo ha transformado mi código.
Y además, aquí también tiene la biblioteca de RIA, la biblioteca de RIA Dome.
Y es que ha tardado, es que ha tardado 30 milisegundos, tío.
O sea, es que es una salvajada la rapidez que tiene.
Vale, también te puedes quitar npm, porque con ban, tú haces ban install y ya te instalan las dependencias.
Ya está, punto.
O sea, también tienes ban, tienes npm y también tienes el testing.
Tampoco necesitas instalar nada de testing porque también tiene sus propios tests.
Puedes hacer los tests aquí.
Puedes hacer index.test.js.
No me acuerdo, pero creo que salen de ban.
Ah, dos puntos test, gracias.
Ban test.
Entonces aquí, no sé.
Claro, tendríamos que instalar alguna, creo que hay una extensión para tener los autocompletes.
Esta es, creo.
Creo que es esta.
Creo que es esta.
La que te da soporte para los imports y todo esto.
Sí, creo que es esta, si no me equivoco.
La deberíamos tener para poder tener los imports que lo detecte y todo esto, ¿vale?
Pero aquí tendríamos el describe, el it, el, no sé, todos estos.
Y ya los podríamos hacer aquí un test.
Index.
It should work, ¿no?
Y ejecutarlo.
Haríamos ban test.
No sé si, ¿ves?
Y ya está.
Ya está.
Should work.
Aquí lo que podríamos hacer, por ejemplo, throw new error.
This is not working.
Y ya tendríamos los tests también, ¿ves?
This is not working.
O aquí podríamos tener el expect, porque si no me equivoco tiene spec, pues spec true to be true.
Vamos a probar este, a ver si es así.
Igual la API no es, porque no me acuerdo.
Sí, sí que es así, ¿ves?
Y ya pasa los tests.
O sea, ya tenéis tests también.
Es un todo en uno.
Es un todo en uno.
Es espectacular.
Es espectacular.
Tiene compatibilidad con Node.js.
Todo el código de Node.js funciona.
Pero es que puedes crear un proyecto de Next.js.
Es un proyecto de Next.js, uno de Remix, uno de Naxx, de Astro.
O sea, puedes crear la aplicación con Astro directamente.
Y creas la aplicación.
Mira, ¿ves?
Aquí tenéis la compatibilidad.
Hay alguna, no es 100% la compatibilidad.
Hay algunas que no.
La han ido priorizando, obviamente.
Pero bueno, que les deben quedar muy poco.
O sea, la compatibilidad es bastante cercana a casi toda.
La velocidad.
Cuatro veces más rápido que Node.js.
Y aquí tenéis la comparativa con algunas herramientas que realmente es espectacular.
Compatible con Common.js y con Enmascrim Modules.
Puedes utilizar la Web API.
Que bueno, esto ya lo estamos viendo en Dino Deploy y todos estos sitios.
Tienes Hot Reloading.
Hostia, esto a nivel de servidor, es que esto me parece espectacular.
Fijaos aquí lo rápido que funciona que puedes ir escribiendo aquí.
Conforme vas escribiendo, se están pasando aquí los tests en tiempo real, ¿sabes?
Porque puedes hacer que mientras escribas se vaya guardando y mientras se va guardando van pasando los tests.
O sea, esto, esto, os voy a contar esto porque esto os va a volar la cabeza.
El Hot Reloading este lo que quiere decir es que si tienes un HTTP, un servidor HTTP o tienes WebSockets,
conexiones WebSockets, esto lo que significa es que sin necesidad de desconectar y de perder el estado,
cambia el código.
O sea, eso es increíble.
Me parece una brutalidad.
Eso no lo había visto yo en ningún sitio.
Tienes plugins, una...
Bueno, la API de BAN para leer ficheros y todo esto.
¿Recomiendas empezar a usarlo?
Hombre, yo recomiendo echarle un vistazo.
Echarle un vistazo, sí.
Aprenderlo y tal.
A mí me parece bastante interesante y creo que poco a poco vamos a ver...
Mira, fijaos en esto, ¿eh?
Comparativa con PNPM.
Que mira que PNPM es rápido, ¿eh?
Que es rápido, pero rápido.
La comparativa de instalación, hacer una instalación de BAN 17 veces más lento PNPM.
Mira, para que le hagamos, le echemos un vistazo.
Vamos a la miduconf.
Vamos a eliminar el PackageLock y el NoModules, ¿vale?
Vale.
Fíjate que le cuesta, ¿eh?
Y vamos a hacer esto.
Vamos a...
Joder, NoModules es que tiene que ser esto una locura.
Vale.
Vamos a quitar BAN aquí, que también había algo por aquí.
Vale.
Le quitamos el PNPMlock para que sea justo, ¿vale?
Para que sea justo.
Primero hacemos el PNPInstall.
Que ya debe tener cacheados.
Porque fíjate que pone descargados.
Descarga algunos, pero tiene muchos cacheados.
Porque fíjate que los tiene cacheados ya en una caché.
Vamos a ver cuánto tiempo tarda.
Que no tarda mucho, pero bueno, tarda unos segundos, ¿no?
Vamos a ver.
Es que esto me parece increíble.
Es que me parece increíble que sea más rápido que PNPM.
Vale.
Ha tardado 20 segundos, ¿vale?
20 segundos.
Vale.
Vamos a quitar otra vez NoModules.
Vamos a quitar...
Fíjate que le cuesta eliminar y todos los ficheros de los que debe haber.
PNPMlock, ¿vale?
No le dejamos aquí ni rastro.
Van Install.
A ver qué.
A ver qué, ¿eh?
Eran 20 segundos antes.
Y este son...
7 segundos.
7 segundos.
O sea, es brutal.
Porque es que estas cosas a mí me vuelan la cabeza.
La diferencia de la experiencia de desarrollo que tienes,
el hecho de instalar...
Y eso que se ha tenido que bajar todos los paquetes de internet
porque no los tenía cacheados en ningún momento.
Claro, si encima ahora, por lo que sea, quito NoModules, ¿vale?
Si quito NoModules y voy a eliminar el lockd, ¿vale?
El lock.
Porque ahora los debería tener en la caché como lo tenía PNPM.
Claro.
Un segundo.
Un segundo.
Con una caché un poco más trabajada que la de PNPM.
Un segundo.
Que le he eliminado el lock, ¿eh?
Le he eliminado el lock, ojo.
O sea, le he eliminado NoModules y el lock.
O sea, ha utilizado la caché global como la que tiene PNPM.
Un segundo.
No, o sea, una salvajada.
Es que lo que decía Van, a mí me parece que estamos en un momento...
Yo sé que mucha gente me dice que infló el desarrollo web,
que no sé qué, no sé cuánto.
Pero, amigos, estamos en un momento tan bonito
en el hecho de poder soñar en hacer despliegues a producción
en menos de un minuto.
En menos de un minuto.
Que imagínate eso.
Imagínate poder hacer un despliegue a producción de tu proyecto
en menos de un minuto.
Donde le pases todos los tests,
donde estés haciendo todas las compilaciones
con TypeScript, con no sé qué, con no sé cuánto,
en menos de un minuto.
Es que me parece increíble.
Y no hay nada parecido.
Pero no se puede instalar en Windows.
Bueno, casi todos los sistemas de Continuous Integration
igualmente no son de Windows.
O sea, qué mal da.
Ah, también puedes...
Esto de npm run dev, también puedes hacer ban run.
Y es que, fíjate en la diferencia.
Tú haces npm run y veis que tarda un poquito,
que tiene como una...
No sé, un microsegundo.
Pero fíjate, ban, que parece...
Es que es instantáneo.
Es espectacular.
Esto te puede parecer una tontería.
Pero yo en mi empresa,
cuando yo estaba trabajando en mi empresa,
os lo voy a enseñar.
Yo cuando trabajaba en la última empresa en la que estaba,
añadí esto, Ultra Runner.
Ultra Runner es una forma de ejecutar los scripts de npm
de una forma mucho más rápida.
¿Por qué?
Porque cuando tú tienes, por ejemplo, un monorepo,
o sea, un repositorio de Gija con un montón de paquetes
y quieres pasar diferentes scripts en cada uno,
como npm run tiene latencia, que la podéis ver aquí.
O sea, latencia significa que va un poquito lento, ¿no?
Aquí lo podéis ver.
A lo mejor, entre que se ejecuta,
o sea, entre que tú le das aquí al enter y se ejecuta,
a lo mejor son 100 milisegundos,
que no es mucho.
Parece que no es mucho.
Pero tú imagínate que esto lo tienes que hacer
con, yo qué sé, 200 scripts.
200 scripts por 100 milisegundos
pueden ser perfectamente 20 segundos.
Y eso, siendo generoso,
porque hay veces que cuando ya tiene un montón de trabajo,
puede ir un minuto
solo en la ejecución vacía del script.
Bueno, pues entonces,
como en su tiempo no existía ban,
sí que existía este Ultra Runner.
Es un runner de monorepos que va bastante rápido.
Ya no está tan actualizado porque ahora ya va lento,
pero la comparativa con NPM hacía que funcionase muchísimo más rápido.
Y fíjate, NPM Run tardaba 150 milisegundos y Ultra,
que es el que yo usaba, 65 milisegundos.
O sea, que ya ahí tenemos una optimización.
Pero yo, si estuviese trabajando en esta empresa
en la que ya no estoy trabajando,
seguramente yo miraría de utilizar ban
solo para ejecutar estos scripts.
Porque lo que puedes hacer es decir,
bueno, voy a utilizar NPM porque a lo mejor todavía lo necesito
para asegurarme que se instalan bien las dependencias y tal,
pero para ejecutar los scripts voy a utilizar ban
porque va a ser inmediato
y vas a ahorrar un montón de tiempo,
un montón de tiempo solo con ese cambio.
Pero bueno, son esas cosas que marcan un poco la diferencia,
que a veces parece que no.
Es que fíjate, NPM Run, 176 milisegundos.
Ban Run, 7 milisegundos.
Que estos son cambios que la gente no se da cuenta,
pero es que es brutal.
Mira, aquí tenéis los test también.
Es increíble.
Este proyecto de verdad es increíble.
Es increíble.
Es tremendo.
O sea, es que es tremendo.
Es que las mejoras que podemos tener a nivel...
Mira, se puede crear...
Yo estoy pensando en crear una cosa.
No os voy a comentar todavía,
pero estoy pensando en crear una cosa
para utilizar ban que puede ser muy chula.
Y mira, por la primera vez
estamos encantados de sacar una release experimental
de ban para Windows.
Qué bueno el logo, ¿eh?
Y ya lo tenéis ahí.
Me lo vendiste.
Voy a migrar una app a ban.
A ver, ¿qué es lo malo de ban?
Lo malo de ban, en realidad, es el despliegue.
Que el despliegue...
Nosotros hicimos ya un proyecto en ban, ¿eh?
Que mucha gente me está diciendo
Ah, pues nunca has utilizado ban.
Pues yo ya he utilizado ban.
O sea, realmente ya he utilizado ban.
Lo hicimos en threads, api, midudev.
Pues este proyecto de la api de threads
la hicimos con ban.
Y tenéis todo el código por aquí.
Lo tenéis por aquí.
Todo esto lo hicimos con ban.
Y la verdad que funcionó increíble.
Ban más Svelkit más Svel.
Ya te digo.
El rediseño de midudev con Astro y ban.
Pues puede ser, puede ser.
O igual hacemos otra cosa, ¿eh?
Igual hacemos otra cosa.
Hacemos un mini Astro, ¿no?
Eso estaría increíble.