10 Years of Best of JS

Hola a todos. Soy Michael de Japón. Estoy muy feliz de ser parte de la nación JavaScript y hoy me gustaría presentar un proyecto llamado Best of JS que creé hace 10 años. Así que aquí está el plan para hoy. Primero, echaremos un vistazo rápido a la evolución de JavaScript a un alto nivel. Luego, les contaré la historia detrás de Best of JS. Y al final, veremos algunas tendencias clave de los últimos años.

Así que comencemos con una rápida visión general de la evolución de JavaScript. Así que hace casi 30 años, JavaScript comenzó como una especie de lenguaje de juguete. Así que principalmente, se utilizaba para agregar cosas como la validación de formularios. Pero lo real era Java, por eso se llamó JavaScript. Era solo un pequeño navegador. Tenía soporte limitado en los navegadores y solo una manipulación básica del DOM. Y no pude resistir compartir un fragmento de lo que llamo vintage HTML JavaScript.

Así que todas las etiquetas, en mayúsculas, algunos comentarios en el medio, por si acaso el navegador no entiende JavaScript. Y también noten que había este atributo de lenguaje porque en ese momento, JavaScript no era el único script que podía ejecutarse en el navegador. Así que todo cambió 10 años después, en 2005, cuando comenzó la revolución Ajax.

Porque permitió aplicaciones ricas en el navegador. Y en ese momento, tuvimos una explosión de nuevas bibliotecas como Prototype, Moodle, Dojo, YUI. Pero había una que ganó el juego. Supongo que lo recuerdas. Es jQuery, por supuesto. Se lanzó en 2006 y se convirtió en una especie de estándar que significa JavaScript en el navegador en ese momento. Tenía una API magnífica, excelente documentación, resolvía muchos problemas. Estaba integrado con WordPress, por supuesto. Y todavía se puede encontrar en todas partes hoy en día. Porque está integrado por defecto en muchos frameworks.

Otra revolución en 2009, cuando JavaScript básicamente se trasladó al servidor con la creación de Node.js por Ryan Dow. Así que, por supuesto, hizo posible ejecutar JavaScript en el servidor. Pero aún más importante, desencadenó una nueva era del ecosistema de JavaScript, comenzando con el gestor de paquetes MPM que se convirtió en el gestor de paquetes más popular. Y había todo un ecosistema que se creó en ese momento. Y lo interesante era que las herramientas en sí estaban escritas en JavaScript. Así que, se construyeron herramientas como Grant, Gulp, Webpack, Transpiler, puede que recuerdes CoffeeScript, Babel, que es realmente importante para la ejecución de scripts en el cliente. Lintels, pruebas. Muchas herramientas.

Y luego entramos en el comienzo de la edad dorada de la SBA, aplicación de una sola página. Así que, estas aplicaciones fueron habilitadas por AJAX porque todo sucede gracias a una solicitud asíncrona realizada por el navegador. La característica clave tenía esta navegación muy rápida entre las páginas. Porque no necesitas una recarga completa. Todo sucede utilizando el API de historial del navegador. Otra buena cosa es que pueden ser fácilmente alojadas en cualquier servicio de alojamiento estático porque utilizan una API JSON para comunicarse con el backend. Así que, son fáciles de experimentar una nueva interfaz de usuario porque puedes intercambiarlas sin cambiar el backend. Y solían tener estas bibliotecas que eran muy populares para crear una aplicación de una sola página. Estaba Backbone que introdujo esta idea de MVC en el navegador. Knockout que introdujo el enlace entre la entrada y los datos. Y lo hice fue refinado y completado por AngularJS. También había esta biblioteca llamada Ember.

Pero la que la gente recuerda más fue React, Vue.js y Angular. AngularJS se transformó en Angular 2. Así que, estas son las tres principales bibliotecas que todavía hoy son las principales bibliotecas de UI. La única desventaja no solo de esto, sino que hay algunas desventajas relacionadas con SBA. A veces se trata de rendimiento. Cuando comienzas pequeño con unas pocas páginas, no hay mucho problema debido al tamaño del paquete. Pero cuanto más agregas páginas y más aumenta el tamaño de tu paquete, puede volverse enorme.

Otra desventaja es el SEO cuando todo es generado por JavaScript. No es genial para los robots que indexan páginas. Además, hay algo de fricción a veces cuando trabajas con el equipo de backend porque tienes que sincronizar entre el equipo de backend y el equipo de frontend. Tienes que asegurarte de que la versión de la API que usas es correcta y no hay cambios disruptivos, por ejemplo, este tipo de cosas. Así que, esa es la razón por la que una nueva UI comenzó hace unos años. Comenzó con lo que llamamos frameworks de pila completa. JavaScript tanto en el cliente como en el lado del servidor.

Y recientemente, el nombre cambió un poco. Lo llamamos meta framework porque están construidos sobre frameworks como React o Vue.js. Así que, el más famoso es Next.js. Y luego tenemos el equivalente para Vue.js que es Next. Y más recientemente, tenemos Remix, Veltkit, Solid. Veltkit está construido sobre el belt, y Solid está construido sobre Solid. Esa es una alternativa muy buena a React. Y luego tenemos nuevos paradigmas porque ahora tenemos componentes del servidor en ambos, React y también vienen al ecosistema de Vue. Estos componentes pueden comunicarse directamente con el backend.

Así que, permiten una integración fluida entre frontend y backend. Y en algún momento, la gente solía burlarse de PHP, pero había muchos memes y chistes sobre PHP llegando a React porque el hecho de que React pueda hablar directamente con una base de datos ahora nos recuerda la simplicidad de PHP. Entonces, pasemos a la segunda parte después de esta una introducción un poco aburrida.

Me gustaría hablar sobre best of JS. Entonces, primero, ¿qué es best of JS? Así que, es una lista creada de proyectos de JavaScript. Y el objetivo es ayudar a los desarrolladores a descubrir tendencias, bibliotecas, y también rastrear el crecimiento del proyecto. También es una herramienta para ayudar a los usuarios a encontrar nuevos proyectos clasificados bajo etiquetas que tengan sentido.

Y también, es una forma de encontrar rápidamente un proyecto que ya conoces si quieres buscar documentación. Y si no quieres llamar a Google o DuckDuckGo cada vez que necesitas algo, trato de hacer la búsqueda muy rápida. Tal vez pueda compartir muy rápidamente mi navegador que está conectado a best of JS.

Puedes ver la página de inicio que por defecto destaca los proyectos populares del día. Y también tenemos, si desplazamos hacia abajo, las últimas adiciones porque sigo añadiendo nuevos proyectos. Y tenemos algunas clasificaciones, también. Y si revisas aquí, tenemos algunas etiquetas populares porque, de nuevo, una de las principales debilidades de la aplicación, uno de los principales intereses es que todos los proyectos están clasificados bajo etiquetas que tienen sentido.

Así que, trato de hacerlas significativas. Volviendo a mis diapositivas. Entonces, ¿por qué fui creado por best of JS?

Así que, la razón es que realmente amo las tecnologías web que funcionan en todas partes. Porque realmente me empodera como desarrollador full stack para crear cualquier cosa. Pero el problema es que las cosas están cambiando tan rápido que puede ser un desafío mantenerse al día.

Y el objetivo es compartir las tendencias también utilizando algunos filtros. Y también, algo importante que quiero es filtrar proyectos que están obsoletos o proyectos que ya no son relevantes. Porque es fácil en la web encontrar una publicación de blog o cosas como, ya sabes, listas increíbles. Básicamente, read me hizo una lista de proyectos. Pero nadie va a eliminar un proyecto que ya no es relevante o un proyecto que se vuelve obsoleto después de unos años más, depende. Así que, trato de ser muy cuidadoso al asegurarme de que todo esté actualizado.

Y luego, sí, también existe este concepto de etiquetas. Sabes, que trato de pensar cuidadosamente sobre cómo etiquetarlos de manera significativa. Así que, lancé todo hace 10 años usando este increíble dominio gratuito llamado js.org. Más tarde, obtuve mi propio dominio. Pero al principio, comenzó así. Así que, estoy agradecido con ellos.

Cómo funciona. Así que, la métrica central es la evolución de las estrellas de GitHub. Puede que te parezca un poco tonto, porque realmente no significa la calidad del proyecto. Pero no es solo un número. Es la evolución a lo largo del tiempo que está integrada. Noté que si un proyecto no recibe ninguna estrella durante, digamos, un período determinado de tiempo, como por un año, significa que generalmente el proyecto ya no se mantiene o no está en buen estado.

Así que, el proceso es que generalmente trato de leer boletines, leer, ya sabes, seguir a personas importantes. Y cada vez que noto un proyecto que es interesante, lo añado manualmente a best of JS, tratando de encontrar la etiqueta, a veces creando nuevas etiquetas que faltan. Y cada vez, cada día, hay un proceso que toma una instantánea del número de estrellas y que almacena todo en una base de datos para que cada día podamos generar una nueva página de inicio computando las tendencias diariamente, semanalmente, mensualmente.

También tengo que mencionar que hay una especie de proyecto hermano llamado JavaScript Rising Stars. He estado dirigiendo eso durante nueve años ya. Tú puedes ver en la captura de pantalla, desde 2016. Es una especie de instantánea de los datos de best of JS que tomo cada año. Y está mejorado por muchos comentarios escritos por mí o por escritores invitados como Ivan o Anthony, personas que son realmente buenas en lo que hacen. Tengo otro proyecto publicado en Astro, que es un gran framework, por cierto.

Y puedo mostrarte muy rápidamente, si quieres. Así que, esta es la edición de este año, lanzada en enero. Y, ya sabes, tenemos básicamente las clasificaciones del año con el proyecto más popular del año, que es ChatZ y UI. Vamos a hablar de ellos un poco más tarde. Volviendo a las diapositivas. Así que, solo algunos números antes de ir a la última parte de la masterclass. Así que, el primer commit fue hace 10 años. Hice manualmente más de 3,000 proyectos. Pero solo hay 2,200 proyectos que aparecen en la UI.

Así que, la razón es que existe este proceso que mencioné que elimina los proyectos que ya no son relevantes. Así que, es parte del proceso. Sabes, los proyectos ganan tracción y con el tiempo sucede que a veces pierden tracción. Nuevos proyectos los reemplazan y así sucesivamente. También tenemos nueve ediciones de los Rising Stars, como mencioné. Y tenemos 205 etiquetas que puedes encontrar en la UI aquí nuevamente. Así que, la más popular es el ecosistema de React. Tenemos el ecosistema de Vue, por supuesto. Y tenemos la biblioteca de componentes.

Así que, veamos, por ejemplo, cuál es la biblioteca de componentes más popular en este momento. Puedes verificar usando diferentes criterios. Por ejemplo, si quiero verificar solo el último mes, verás que, nuevamente, es ChatZ y UI. Fue el proyecto más popular. Puedes ajustar y puedes incluso agregar más etiquetas. Por ejemplo, si quieres limitar tu búsqueda al ecosistema de Vue, puedes hacer clic aquí y obtienes otra vista. Así que, si tienes tiempo, por favor revisa Face.js. Volviendo, entonces me gustaría pasar a la última parte de la masterclass. Así que, me gustaría discutir algunas tendencias clave y algunas historias de éxito que elegí, de este análisis. No esperes que sea exhaustivo. Son solo algunas selecciones aleatorias.

Así que, primero, creo que la tendencia más significativa es TypeScript. Porque hace diez años, había varios JavaScripts compitiendo. Había Flow de Facebook que se usaba mucho en el ecosistema de React, TypeScript, pero también algunos lenguajes como CoffeeScript. Estaba Babel, para compilar y agrupar código para el navegador. No había un ganador claro. Un momento clave ocurrió cuando el framework Angular fue escrito en TypeScript en 2014. En ese momento, no era una elección obvia. Y luego, sí, si avanzamos rápidamente, diez años después, es una locura. TypeScript es realmente el estándar de facto para escribir JavaScript. Incluso tenemos nuevos entornos de ejecución que entienden y hablan TypeScript por defecto.

Así que, Deno se lanzó en 2018. Burn se lanzó en 2021. Ambos son grandes herramientas para escribir cosas como scripts, por ejemplo. Porque puedes escribir TypeScript sin las mismas herramientas. Quiero agregar dos noticias emocionantes del año pasado. Hubo este nuevo registro de paquetes llamado GSR, del equipo de Deno. Así que, es un registro que soporta TypeScript de manera nativa. Además, otra gran noticia fue el hecho de que TypeScript va a ser entendido por Node.js directamente, sin ninguna bandera, desde Node.js 23. No es una compilación completa. No va a lanzar errores, pero va a poder leer y entender tu código TypeScript eliminando anotaciones.

Luego, otra cosa de la que me gustaría hablar es la evolución del estilo y cómo básicamente pasamos de CSS, CSS puro, a componentes headless. Todo comenzó hace más de diez años, 15 años, con Bootstrap. Bootstrap fue un gran framework CSS con grandes ideas y un gran soporte para diseño web responsivo. Aún recuerdo esos días, me sorprendía por los componentes responsivos. Solía verificar cómo funcionaba, y todas las media queries eran manejadas por el framework CSS. También, esta clase utilitaria que podías poner para hacer que tus componentes o tus elementos HTML fueran amigables para móviles. La principal desventaja era que eran muy opinativos sobre el diseño. Así que, obtienes un aspecto y una sensación consistentes desde el principio, pero puede ser difícil de personalizar. Tienes que luchar con el CSS a veces y evitar conflictos en las clases, especialmente cuando tratas con una gran base de código.

En ese momento, también había esta tendencia de generar CSS a partir de lo que llamamos preprocesadores. Así que, tenemos este tipo de CSS, headless, stylus, post-CSS. Así que, todas estas herramientas podían generar CSS, dándote el poder de usar cosas como variables, funciones. Y también había la tendencia de CSS en JavaScript. Era una gran opción para SPA porque las aplicaciones de una sola página son muy dinámicas, así que a veces necesitamos ajustar el estilo dependiendo del estado. Así que, al poder escribir los estilos en JavaScript, obtienes mucha flexibilidad. Y también, pudimos limitar los estilos y pudimos hacer que los estilos estuvieran cerca del código al que pertenecen. Y las dos soluciones más famosas fueron style components y emotion. Pero hay algunos compromisos. Cosas como la sobrecarga de tiempo de ejecución, lo que significa que hay algunas cosas sucediendo en tiempo de ejecución cuando ejecutas este tipo de bibliotecas. El motor de JavaScript va a actualizar la cabecera de tu página para hacer algunos cambios en los estilos.

Además, tienen un impacto en el tamaño del paquete porque en JavaScript, añade más JavaScript a veces a un paquete que ya está grande si tienes mucha lógica en tu aplicación. Además, la idea, cuando quieres lidiar con el renderizado del lado del servidor, puede añadir complejidad. Y todas estas tendencias llevaron a algo llamado componentes headless. Esa es una tendencia que encontré muy interesante en los últimos años. Entonces, ¿qué son los componentes headless? Son componentes sin estilo, lo que significa que vienen sin estilo. Tienes que estilizarlo tú mismo. Pero vienen con una gran accesibilidad incorporada. Cuando piensas en accesibilidad, puedes pensar en usuarios con discapacidades, pero también piensas en usuarios con recursos limitados, cosas como atajos de teclado, por ejemplo. Todos los detalles son difíciles de acertar al principio cuando quieres escribirlos tú mismo. Así que, estas bibliotecas, como tenemos ARIA, LSUI, Redux Primitives, te ayudan a crear aplicaciones que manejan todos estos aspectos tediosos.

Y ahora quiero hablar de Tailwind CSS, porque ese es uno de los estándares actuales en el desarrollo web. Así que, Tailwind CSS, debes haber oído hablar de eso, utiliza este enfoque de CSS atómico. Así que, en lugar de escribir estilos en tu CSS, los escribes directamente en HTML como atributos. Así que, ya no hay más archivo CSS. Ya no hay más riesgo de conflicto debido a todos los estilos que pueden chocar. También ayuda a obtener un sistema de diseño consistente porque tienen, por defecto, un sistema muy bonito. Proporcionan, por ejemplo, un espacio de escalado. También tienen una gran Dx, experiencia del desarrollador, si usas las herramientas adecuadas en el IDE. Y hay algo llamado optimización del tiempo de construcción, lo que significa que hay un proceso que asegura que mantienes, envías solo la cantidad correcta de CSS a tu navegador. Así que, de alguna manera, es una solución a muchos problemas que describí muy brevemente anteriormente.

Otra razón por la que se convirtió en un estándar, debido a la gran documentación. Además, el hecho de que escala muy bien, sin importar el tamaño de tu aplicación. También, para los desarrolladores, es genial poder reutilizar el conocimiento que has acumulado en diferentes proyectos. Y por último, pero no menos importante, hay una comunidad nativa y un enorme ecosistema. Algo interesante es que hay este tipo de relación amor-odio. Algunas personas aman, algunas personas odian. Tenemos que decir que a veces se siente extraño depender de la concatenación de cadenas. He incluido aquí un fragmento de mi propia base de código. Este es el cuadro de búsqueda de la tecla de comando que ves en algunos sitios elegantes. Puedes ver este enorme nombre de clase.

Así que, cuando tienes que depurar eso, no es tan divertido. Así que, esa es una razón por la que hay algunas alternativas que proporcionan tanto seguridad de tipos como también la misma idea de procesamiento en el tiempo de construcción para asegurar que enviamos solo la cantidad correcta de CSS al navegador. Hay Uno-CSS de Anthony Fu. Hay Talex de Meta. Hay Panda del equipo de Chakra. Algo que encontré muy interesante es que a veces no es el mejor concepto el que gana, sino más bien la mejor ejecución. Lo que significa que también es el ecosistema, la documentación y todo lo que sucede en las redes sociales que ayuda al crecimiento de un proyecto.

Así que, de alguna manera, TeleWin CSS cumple con todas estas casillas. Y otro proyecto que me gusta destacar es ChatCN UI. Viene porque, de alguna manera, está relacionado con todo lo que mencioné antes. Está relacionado con el componente headless porque está construido sobre Redix UI. También está relacionado con TeleWin CSS porque es algo que puedes personalizar muy fácilmente con TeleWin CSS. Fue el proyecto más destacado en 2023 y 2024 en el proyecto Rising Stars que introduje anteriormente.

Y cuando llegó, fue un tipo de cambio de juego porque, en lugar de proporcionar componentes que instalas ejecutando npm install, copias y pegas los componentes en tu base de código. También hay una herramienta de línea de comandos que puede ayudarte con eso, pero aún así, al final del día, el código pertenece a tu base de código. Lo que significa que tienes propiedad y puedes personalizar las cosas como quieras. Así que, por eso mencioné que es genial. Es realmente impresionante cómo puedes personalizarlo. Y ha creado todo un ecosistema porque esta CLI puede funcionar no solo con los componentes de ChatCN UI, sino con cualquier registro que básicamente siga el contrato que fue introducido por ChatCN UI.

con cualquier registro que básicamente siga el contrato que fue introducido por ChatCN UI. Así que, tenemos la equivalencia de ChatCN para Vue, para Svelte, para Solid. Y recientemente, en Best of JS, introduje una etiqueta llamada ChatCN. Creo que puedes verlo aquí. Sí, ChatCN. Puedes ver el código disponible del registro de ChatCN. Así que, la mayoría de los proyectos aquí están inspirados por ChatCN.

Lo que significa que puedes agarrar fácilmente estos componentes e integrarlos en tu base de código. Y el último punto que quería señalar sobre las tendencias, ya sabes, es la herramienta. Porque al principio, dije que con Node.js, teníamos muchas herramientas que estaban escritas en JavaScript mismo. Es genial, pero la única desventaja es que no son súper rápidas, especialmente cuando tratas con una gran base de código. Pero esa es la razón por la que a lo largo de los años, obtuvimos nuevas herramientas que están escritas principalmente en Go y Rust. PSBuild fue una especie de pionero en este espacio y es un empaquetador de bajo nivel que es utilizado por muchas otras herramientas.

Luego está Vite. Así que, Vite es una parte clave del ecosistema porque potencia muchos proyectos, incluyendo frameworks, bibliotecas. Estoy hablando del framework Astro, por ejemplo. Hay Vitess, una prueba moderna. Está inspirada en la API de Jest, pero tiene un gran soporte para TypeScript. Siempre es un placer trabajar con ella porque funciona de inmediato. Y también está Beom, que es un reemplazo de ESlint y Pwt. Es más rápido que estas herramientas, pero conduce a menos boilerplate porque combina estas dos herramientas. Además, tengo que mencionar que hay herramientas más emocionantes que llegarán pronto. Hay esta empresa llamada Void Zero, creada el año pasado por Ivan Yu, creador de Vue.js.

Creo que eso es todo lo que quería compartir sobre las tendencias. Solo para resumir, hace diez años, estaba construyendo SPA con React, Webpack para compilar todo con Babel. Estaba usando un preprocesador llamado Stylus. Diez años después, usé Next.js. Usé componentes de React. Por supuesto, TypeScript en todas partes. Todo se ejecuta en un monorepo. Es bastante divertido.

Nuevamente, el mismo problema que hace diez años. Es difícil mantenerse al día. Creo que lo mejor de JS sigue siendo relevante. Espero que te ayude a navegar este paisaje en constante cambio. Por favor, házmelo saber. Échale un vistazo. Puedes encontrarme en GitHub.

Gracias a todos. Diviértanse en JS Nation. Hablamos pronto.