El benchmark del mal, amigos. Ha habido una pelea, una pelea brutal en las redes sociales porque ha salido como un benchmark un poco polémico.
Lo ha sacado Mateo Colina, que es uno de los programadores más importantes que está trabajando en Node.js y que también es el maintainer principal de Fastify.
Que Fastify es un framework muy interesante de Node.js, es una alternativa express, que bueno, está genial. Pero ¿qué ha pasado? Pues que Mateo, con buena intención me imagino, lo que ha pasado es que ha hecho una comparativa que como podéis ver ha eliminado.
Pero yo he estado escudriñando los entresijos de internet para traeros toda la información, por supuesto, porque no os iba a dejar aquí esto a medias.
Y tenemos el artículo que le ha guardado WebArchive, así que vamos a echarle un vistazo.
SSR Performance Showdown, el 26 de agosto, lo sacó Mateo. ¿Y de qué hablaba? Pues tenía un script, como un HTML, como algo que iba a renderizar en el servidor y comparaba con diferentes frameworks.
Obviamente, primero con el suyo, que es Fastify, con el suyo de Fastify, pero luego Fastify, además que te decía que podía devolver 975 peticiones en cada segundo.
Luego, ¿qué ha pasado? Pues bueno, lo ha comparado con Solid, que es una alternativa a React, por si no la conocéis.
Solid.js, es una alternativa a React, reactiva, mucho más ligera, más pequeña.
Y con Solid teníamos 863 peticiones, menos, obviamente, que Fastify.
Luego Vue, 353, bastante mal parado.
Pero luego Svelte con solo 171, muy poco.
Y finalmente React con 138 peticiones, o sea, un 10% de lo que podía hacer Fastify.
Y aquí tenemos la gráfica final, que da bastante grima, ¿no?
Cuando la ves y dices, ostras, qué penita, ¿no?
El hecho de Fastify HTML, pues aquí, hasta aquí arriba.
Solid, pues que defiende un poco el tipo.
Vue, se queda un tercio, Svelte y React por los suelos.
¿Cuál es el problema, amigos, de los benchmarks?
Que no hay que fiarse de ellos.
Y más cuando, justamente, quien ha hecho este benchmark es el creador de Fastify.
Que, oh, sorpresa, es el que ha quedado el primero.
Sí, es lo que dice Q15.
Dice, últimamente el tema WordBench o Benchmark se ha visto solo como tema de salseo y toxicidad.
Yo, la verdad, que los temas de benchmark yo creo que deberían ser tanto de código abierto
y que sea más bien la gente de los equipos los que añadan su propio benchmark, ¿no?
Porque me parece que si no, se pueden cometer muchos errores.
Y ser un poco tendencioso, porque fijaos aquí que, qué casualidad, Fastify ha sido el que ha quedado el más arriba.
Pero empezó la liebre ya con Rich Harris, creador de Svelte, y dijo, ojo, cuidado, que esto está mal.
La implementación que está utilizando Mateo está haciendo mucho más trabajo que los otros.
Entonces, no estás haciendo una comparación real de manzanas con manzanas.
Lo he arreglado, he añadido Svelte 5 para también hacer una comparación más fiable.
Parece ser que somos más rápidos que Fastify.
Aquí tenemos el que sería Svelte roto, el original.
Luego el Svelte arreglado, que sería casi igual que Fastify.
Y Svelte 5, que es todavía más rápido.
O sea, que ya tenemos aquí como, ay, Dios mío, aquí algo ha pasado, algo ha pasado, ¿no?
Dice, ¿qué es lo que ha pasado?
Bueno, lo que ha pasado, y esto es muy interesante, ya lo dice Rich Harris, dice, bueno, aquí tenemos una pequeña pista.
El código ha sido escrito por un LLM, vamos, por una inteligencia artificial como ChatGPT y todas estas cosas, ¿no?
Que está muy bien, es una herramienta muy útil para muchas cosas, pero que seguramente podemos estar todos de acuerdo
que no es la mejor forma de hacer benchmarks, porque es peligroso.
Y esta es una lección.
Dice, lección 2, nadie se puso en contacto con nosotros para chequear si lo que se estaba haciendo era correcto antes de publicar este post.
Creo que nos hubiéramos dado cuenta de esto y lo hubiéramos arreglado, así que hay que tener cuidado.
Y lo más importante aquí es que cada vez que veas un benchmark como estos, tienes que asumir que no tiene ningún tipo de sentido
hasta que se pruebe lo contrario.
Porque al final, como podéis ver, suele haber muchos errores y que no son muy de fiar, ¿no?
En este caso, pues ya lo han arreglado.
Pero claro, esto no podía seguir así.
Hay más cosas, porque este que es el de Svelte, también el de Solid se ha quejado.
Ha dicho, bueno, me he puesto a mirar el benchmark y he visto unas cuantas inconsistencias.
Y esto sería una vez arreglado.
Claro, porque dice Fastify, lo único que hace es re-renderizar y no es equivalente, porque Solid hace mucho más trabajo.
Entonces, el de Before sería antes de arreglarlo, luego el After arreglado y luego sin la hidratación.
Porque claro, la hidratación no la hace Fastify, es injusto que sí que la haga Solid 10 o los otros frameworks.
Y aquí tendríamos 1.305, o sea, estaría por encima también de Fastify.
O sea, Solid también estaría por encima de Fastify.
Pero lo peor de todo esto, y lo bueno del código abierto, y es que tenéis aquí todo el código del benchmark, ¿vale?
Todas las comparativas que se han hecho con Priya, con React, Solid, Svelte, Vue, todo, ¿no?
Y cómo se ha ido haciendo todo.
Pues el tema es que lo bueno del código abierto es que puedes ver qué es lo que ha pasado.
Y lo que ha pasado, por ejemplo, es que en la versión de React hay un error brutal, brutal, muy importante,
porque estaba utilizando la versión en modo desarrollo.
Y el bueno de Dan Abramoff ha entrado y ha dicho, oye, claro, en modo desarrollo no lo puedes comparar
porque React hace un montón de chequeos para ver si hay errores, para darte información interesante y tal.
Y entonces, cuando lo pones en modo producción, vas a ver que funciona mucho mejor.
Y aquí podéis ver un poco la comparativa.
Tendríamos 178 requests, sería de React en modo desarrollo, pero en modo producción ya son 682,
que ya empieza a acercarse también bastante a Fastify, ¿vale?
Y esto sin arreglar ningún tipo de cosa del código, solo con este pequeño cambio.
O sea, solo con el cambio de hacerlo en modo producción ya estaríamos viendo esto.
También la gente de Vue...
También la gente de Vue ha entrado.
¿Por qué? Porque resulta que en Vue también había problemas.
Aquí lo tenemos.
Alinear la implementación de Vue.
O sea, la implementación de Vue que resulta que una vez arreglado teníamos 846.
Y cuando es en modo producción, 923.
Que son bastante parecidos también a lo que hacía Fastify.
¿Qué es lo que ha pasado al final de todo esto?
Pues que, como nos hemos dado cuenta, ningún benchmark era fiable.
Que esa es la razón, la verdad, esa es la razón por la que ha eliminado el propio Mateo Colina.
Ha eliminado el benchmark que estaba corriendo como pólvora y estaba habiendo bastante sangre y la ha eliminado.
¿Ves? Aquí este post no está disponible porque lo ha quitado.
Lo ha quitado.
Lo ha quitado y ha dicho, oye, he eliminado el tweet y publicaremos una versión actualizada pronto.
¿Vale? Se ha metido aquí un montón de gente porque había gente que al principio, obviamente, ahora ya no tanto.
Ahora se ha bajado un poco el debate.
Pero durante un momento ha habido bastante polémica porque lo que se veía es que, claro, fíjate.
Dice, nada lleva a la gente que mantiene los frameworks juntos, nada los une más que publicar un benchmark picante para que puedan trabajar juntos.
Y es que fíjate que en los últimos cómics puedes ver en el mismo repositorio cómics de Rich Harris, Ryan de Solid, Dan Abramov.
Tenemos aquí el de Priak.
Tenemos también gente de Vue.
O sea, que aquí en este pull request todos, en este repositorio han estado trabajando todos los frameworks.
Carniato, exacto.
Ha estado trabajando todos los frameworks para arreglar el benchmark.
No comparan con Angular porque le gana a todos.
Puede ser, puede ser.
Lo bueno es que de código abierto alguien lo podría añadir.
Una cosa que sí que es importante, y es lo que os quería decir sobre el tema de los benchmarks,
que tengáis mucho peligro, especialmente cuando es un benchmark que lo está haciendo el creador de esa biblioteca.
Porque si es el creador de la biblioteca, no va a publicar un benchmark en el que salga perdiendo o que salga el último.
Y que siempre, seguramente, va a intentar de alguna forma, aunque sea, o sea, no intencionalmente, de forma, no sé, subconsciente, ¿sabes?
Pues va a aparecer algo, ¿no?
Que va a hacer que aparezca ganador.
A lo mejor no de forma muy fiable.
Así que tengan cuidado, ¿vale?
Si hubiesen comparado con Angular, la gente de Angular habría hecho el benchmark de nuevo usando Signas y Simson.
Sí, pero es que al final es lo que dice uno, ¿no?
Que estamos comparando naranjas con manzanas y con peras, porque cada uno hace un trabajo totalmente distinto a Fastify.
Fastify, lo que estaba diciendo Mateo en su artículo, es cómo de rápido podía renderizar HTML estático.
O sea, server-side rendering, pero estático.
Y claro, yo, sinceramente, no tendría mucho sentido utilizar uno de estos frameworks para simplemente hacer HTML estático, porque a lo mejor para eso utilizarías otro tipo de soluciones.
Claro, él habla de Fastify HTML, pero comparar Fastify HTML con React, con Vue, con todo este tipo de cosas que, obviamente, están pensados para hacer la web interactiva,
pues no sé si tiene mucho sentido, pero es que aún así, como se ha visto, no tiene mucho valor porque estaban mal los benchmarks, así que hay que tener un poco de cuidado.
La lucha de Fastify es con Express y otros, efectivamente, ese es el punto.
Yo creo que se ha equivocado con su lucha, porque no tiene mucho sentido que se pelee ahora con Ria, que es que, ¿qué sentido tiene ponerse a compararse con Ria?
No tiene ningún tipo de sentido, no tiene ningún tipo de sentido.
Pero bueno, hay estado peleándose, ¿vale? Y ya han hecho todas las paces, han retirado el tuit y todos, todos contentos.