El Estado de las Herramientas de React

¡Hola Berlín! Espero que todos estén bien. Mi nombre es Jonny Burger. Soy de un lugar llamado Zurich, Suiza, lo que significa que puedo entender a los alemanes, mientras que los alemanes no pueden entenderme. Así que estoy muy feliz de tener este superpoder y estar aquí en Berlín.

Y mi charla va a ser... espera, primero déjame hablarte del proyecto en el que estoy trabajando. Soy el mantenedor de ReMotion, que es un framework que te permite hacer videos en React. Puedes escribir el componente, animarlo, crear videos MP4 reales e incluso crear aplicaciones que aprovechen el video programático.

Y para ese framework, tengo que usar muchas herramientas diferentes. Hay tantas herramientas por ahí y estoy muy confundido. Y si alguien pudiera ayudarme a navegar, alguien imparcial, decirme para qué sirven todas estas herramientas, porque una nueva sale cada semana, bueno, te tengo cubierto. Estas son más de 20 herramientas de JavaScript que los desarrolladores usan comúnmente y las he organizado en transpiladores, bundlers, runtimes, linters, test runners, type checkers, formatters y package managers. Sé que es mucho y debemos reconocer que no tiene sentido que uno conozca todas las herramientas de una vez. Pero creo que en general, deberías usar una herramienta de cada categoría.

Voy a repasar todas las herramientas en 20 minutos para contarte un poco sobre ellas y darte una opinión imparcial. Va muy rápido. Ok, Babel, es el transpilador original que originalmente se llamaba 6to5. Ha tenido un buen recorrido durante 10 años. Es el más flexible. Tiene la mayoría de las transformaciones. Pero la gente se ha quejado de su velocidad durante un tiempo. Así que han surgido nuevos en el mientras tanto y no recomendaría que lo uses para un nuevo proyecto, excepto para React Native, donde todavía es fundamental.

SWC es el niño de Rust en el bloque, y es el nuevo valor por defecto en Next.js. También cuenta con un gran respaldo de la industria con Vercel, de quien acabas de escuchar. Así que no puedes equivocarte si lo usas. Es muy estable y mucho más rápido que Babel.

ESBuild es un transpilador escrito en Go y es el valor por defecto en Vite. Así que si usas Vite, estás utilizando ESBuild en el fondo para empaquetar tu aplicación de producción. Y Vite también es muy rápido y muy robusto. Tiene un gran respaldo de la industria, especialmente porque Vite lo utiliza.

Y también puedo recomendarte que lo uses. Ahora vamos a hablar de uno que es un poco menos conocido. Se llama Sucrase, que en realidad es el transpilador más rápido. Y está escrito en TypeScript. Así que podrías pensar que es más lento que los compiladores que están escritos en Go o en Rust. Pero no, en realidad no importa. Y compila muy rápido. Pero también tiene algunos problemas que me impiden recomendártelo. No tiene como objetivo cumplir completamente con las especificaciones, sino que es más práctico. Se describe a sí mismo como experimental y divertido, lo cual suena realmente divertido. Y una cosa interesante es que si le das código inválido, podría generar un archivo JavaScript inválido, lo cual no es lo que probablemente quieres. Y además, no tiene realmente un logotipo como herramienta de JavaScript. Así que, desafortunadamente, no puedo recomendártelo.

TypeScript también es un transpilador, si lo piensas, porque convierte archivos TS en archivos JS. Y no lo recomendaría en una pila de front-end usarlo como un transpilador, por ejemplo, en webpack. Pero si también necesitas generar archivos de definición .d.ts de TypeScript, básicamente necesitas usar TypeScript porque es la única opción.

Entonces, para bibliotecas o aplicaciones de back-end, te recomiendo usar TypeScript como el transpilador. Entonces, ¿cuál deberías elegir? Depende, pero en realidad, muchas veces no puedes elegir. Tu framework o tu bundler toma esa decisión por ti. Así que es bueno saber qué opciones hay. Es más responsabilidad de los desarrolladores de frameworks decidir cuál es el correcto.

Ahora, hablemos de la diferencia entre un transpilador y un bundler. Mientras que un transpilador convierte un solo archivo que tiene una sintaxis que no se puede ejecutar en un runtime o en un navegador en algo que se puede ejecutar, el bundler toma muchos de los archivos transpilados y los agrupa en uno solo. Y el más popular, déjame ver otra vez, fui un poco rápido. Estoy tratando de ir rápido. Webpack, por supuesto, es el estándar de oro y se utiliza en todos los principales frameworks hasta que Vite apareció y ahora también está reemplazando a NexGIS. Pero debido a esto y a la gran cantidad de opciones que tiene, por supuesto, es mucho recomendado.

Bien. Llegué a la diapositiva correcta sobre Rollup, que prioriza los módulos ES, muy moderno y también mucho más rápido. Pero la cosa es que no admite el reemplazo de módulo en caliente. Entonces, en desarrollo, no podrías guardar y actualizar tu componente React. Por lo tanto, no te recomendaría usarlo por sí solo. Sin embargo, es una parte esencial de Vite. Vite es un bundler muy popular en la actualidad que durante el desarrollo no hace ningún empaquetado sino que hace algo llamado desempaquetado. Simplemente sirve todos los archivos JavaScript directamente al navegador sin hacer nada y eso solo funciona porque utiliza módulos ES. Como sabes, aún no estamos completamente listos como ecosistema de JavaScript para usar solo módulos ES. Vite o Rollup pueden generar cierta fricción. También está Parcel, que es un poco más conservador, se acerca a las ideas de Webpack, las que funcionan. Pero busca o quiere que uses menos configuración, que sea más fácil usar un bundler. Y tiene algunos valores predeterminados muy buenos como el transpilador SWC que, de serie, jaja, lo hace más rápido que Webpack. No es muy popular, supongo, porque no está muy por delante de Webpack y la gente tiene miedo de migrar. Pero definitivamente lo recomiendo. A continuación está Snowpack.

De acuerdo. TurboPack, habrá una charla a las 2 p.m. que te recomiendo escuchar y revisar. Será el sucesor de Webpack creado por el creador de Webpack y contará con un gran respaldo de Vercel. Pero no hay instrucciones de instalación y solo 10 páginas de documentación, así que por ahora lo consideraremos solo un montón de hype. Pero veamos qué tiene que decir Tobias al respecto.

De acuerdo. Pasemos al tiempo de ejecución. Y, por supuesto, todos están usando Node.js. Creo que el 99% de ustedes está usando Node.js. Me sorprendería mucho si no fuera así. Millones de módulos de MPM es lo que nos permite construir cosas poderosas, negocios de miles de millones de dólares porque el ecosistema es tan bueno. Ahora hay algo nuevo, Dano, que supongo que técnicamente es mejor, ¿verdad? Es un poco más rápido, un poco más sensato, un poco más seguro e incluso admite TypeScript de forma nativa. Pero ha pasado un tiempo desde que salió, y siento que la adopción no ha sido realmente tan grande. Y creo que la razón de eso es que la historia de compatibilidad no es muy convincente. Básicamente, tienes que volver a escribir o construir un nuevo ecosistema desde cero. E incluso con la nueva compatibilidad de NPM, no puedo simplemente dejar Node y todos mis 1,000 módulos de Node porque hay algunas incompatibilidades. Lo que me emociona en cambio es Bunn. Bunn es un nuevo tiempo de ejecución, y el creador de Bunn también dará una charla el lunes, que se supone que es más rápido que Node y compatible. Entonces, básicamente, están tratando de construir una gallina de los huevos de oro. Podemos ejecutar el código que ya hemos escrito, pero más rápido. Si tienen éxito con esa misión, será enorme y ahora hay un respaldo serio detrás de ello y realmente quiero que Bunn suceda.

Pasando a los linters, eslint, por supuesto, es el más famoso porque tiene miles de reglas. Podemos verificar todo, verificar muchos errores. Creo que tengo alrededor de 300 reglas de lint en mi proyecto. E incluso podemos crear reglas de lint específicas del framework. Así que hay un preajuste para Next y hice un preajuste para Remotion para detectar algunos errores comunes que los usuarios del framework cometen. Lo interesante de eslint es que han anunciado que lo reescribirán completamente desde cero y no utilizarán TypeScript.

Elección muy loca si me preguntas, y no entiendo por qué. Pero sin embargo, por supuesto, eslint, es imprescindible. Y como en cada categoría, hay un competidor que está surgiendo y está escrito en Rust. Se llama Rome. Por supuesto, es mucho más rápido que eslint, pero por el momento solo tiene 80 reglas. En el futuro, probablemente podrás modificar las reglas, pero todas tendrán que estar escritas en Rust. Y debido a que actualmente detecta muchos menos errores, solo te lo recomendaré si quieres menos errores en tu proyecto.

Bien, gestores de paquetes, y aquí no tengo tiempo para discutir sobre lo bueno y lo malo. Desafortunadamente, todos los gestores de paquetes son muy buenos y realmente no me importa cuál uses. Pero lo que no debes hacer es usar varios gestores de paquetes en el mismo proyecto, porque entonces terminarás con múltiples archivos de registro y podrías introducir errores sutiles. Por supuesto, han creado un gestor de gestores de paquetes llamado core pack, y ahora se envía junto con Node.js. Puedes ejecutar core pack enable en tu proyecto y lo que te permitirá hacer es especificar qué gestor de paquetes debe usar ese proyecto, y luego se apoderará de los comandos y se asegurará de que, para cada proyecto, se descargue el gestor de paquetes correcto y la versión correcta, y si intentas usar un gestor de paquetes diferente, fallará. Así es como podemos evitar que varios gestores de paquetes interfieran entre sí.

Los comprobadores de tipos han sido de gran ayuda para mí, y por supuesto, TypeScript, el Santo Grial de nuestras herramientas, nos ha hecho a todos mucho más productivos y realmente siento una conexión espiritual cuando uso TypeScript. Es tan bueno. La única oración que tengo es que podría ser un poco más rápido. Por supuesto, se recomienda mucho TypeScript. Y comenzando con esta cosa llamada STC, es como TSC, pero un Comprobador de Tipos Rápido, muy ingenioso, escrito en Rust. Un hombre, el autor de SWC, se ha propuesto ayudar a nuestra humanidad escribiendo un comprobador de TypeScript más rápido en Rust. No sé si tendrá éxito. Actualmente, está publicando actualizaciones de progreso semanales en su blog. En este momento, aproximadamente la mitad de los errores que deberían aparecer realmente aparecen. Supongo que hacer el resto es la parte más difícil. Así que actualmente no puedo recomendarlo porque no tiene un logotipo. ¿Cómo despegará una herramienta si no tiene un logotipo genial? Así que por favor, alguien haga un logotipo para STC. Cinco segundos de descanso. Necesité cuatro asuntos. Prettier. Tiene pocas opciones y es opinativo para que los desarrolladores no discutan sobre los puntos y comas.

Sí, y si me permites agregar, actualmente estoy usando Vite activamente y el único problema real son los autores de bibliotecas que no admiten Javascript estándar. Por ejemplo, si usas AWS, muchas de las bibliotecas de cliente de AWS Amplify son básicamente solo scripts de webpack. Suponen que muchas de las dependencias de nodo están shimmed. Entonces, ya sabes, si usamos Vite y nos quejamos a los autores de las bibliotecas, creo que todos podemos estar en un lugar mejor pronto. Muy bien. ¿Es hora de abandonar yarn? Esta cosa de la versión 2, debo admitir, fue un poco, fue un poco extraña, pero, ya sabes, creo que si no funciona para ti, es relativamente fácil cambiar a pnpm. Entonces, si te funcionó bien, quédatelo. Y si no, hay otras herramientas que puedes adaptar relativamente fácilmente. No lo veo como un problema demasiado grande.

Bien. Tenemos un viajero en el tiempo de 2018 que pregunta, ¿qué opinas de flow? Bueno, probablemente será el futuro. Sí, no recomendamos usar flow hoy en día. Sí, ni siquiera merecía un lugar en la presentación, desafortunadamente. Sí, creo que es una de esas historias tristes donde, desde un nivel conceptual, eran más correctos que TypeScript, pero la experiencia del desarrollador no está ahí. Y a los desarrolladores les importa más la experiencia que la corrección, creo. Muy bien. Veamos qué más tenemos aquí. Oh, tenemos un viajero en el tiempo del año 2008 que pregunta, ¿por qué no mencionaste jQuery? Podría expandir esto en una charla de dos horas, así que se trataba solo de herramientas que usarías para React. Estamos en React Day Berlin, y sí, en realidad Astro es lo nuevo, pero como era React Day, no lo mencioné.

Bien, aquí hay un poco de... Espera, ¿me... perdí la pregunta? Había una pregunta muy interesante sobre ¿Por qué crees que Denno no ha despegado tanto como algunas personas esperaban? Lo he probado y es difícil hacer que todo funcione. Incluso en un proyecto pequeño, al menos tienes cientos de módulos de NPM y Siempre algo no funciona. Todo tiene que funcionar, tiene que ser 100% ideal para que lo adoptemos, ¿sabes? Pero esa no es la realidad. Y también creo que no es suficientemente revolucionario como para justificar que invirtamos todo el tiempo en migrarlo y Creo que BAN es mucho más prometedor. Claro, y creo que tal vez agregaré mi propia pregunta a esto porque una cosa que Denno está haciendo como negocio es que son una plataforma de vanguardia, ¿verdad? Como, ya sabes, ejecutan el tiempo de ejecución de vanguardia. Y luego tienes, ya sabes Cloudflare, por ejemplo, o Vercel que utiliza el tiempo de ejecución de vanguardia de Cloudflare y están comprometidos con el uso de un JavaScript puro y estándar del navegador. ¿Crees que estos diferentes sabores de JavaScript desaparecerán lentamente en favor de los estándares del navegador? ¿O crees que habrá un futuro de transpilación para siempre? Espero que todo se estandarice y ya está. Quiero decir, tenemos el navegador, tenemos diferentes navegadores, Node, Deno, One, todos tienen pequeñas diferencias. Creo que hay un grupo de trabajo llamado Winter CG que está tratando de alinear eso para que esperemos que haya más y más estandarización en el futuro y no tengamos problemas de interoperabilidad tan grandes. Sí, creo que con todas estas herramientas, ahora estoy haciendo mis propias preguntas, lo siento. No me importa lo que quieras tú. Una de las cosas de las que solíamos hablar mucho en el pasado era esta idea de la fatiga de JavaScript, ¿verdad? Y hemos pasado. Solía estar en el cliente, solía estar en el tiempo de ejecución, ya sabes, solía ser qué marco de trabajo usas. Pero ahora parece que ese problema se ha trasladado al lado de las herramientas. ¿Ves algún claro ganador emergiendo donde, como tal vez en unos años, podríamos reducir las cosas y sería más obvio para, por ejemplo, un desarrollador web elegir solo el estándar y no pensarlo demasiado? Creo que por ahora, los aburridos, incluso si son lentos, están ganando y se están negando porque son muy probados en batalla. Y si hay nuevas incorporaciones, si alguien más está ganando a los que son muy maduros en este momento, solo necesitan tener una compatibilidad clara y tener beneficios tangibles sobre lo que estamos usando ahora mismo. Así que no veo que cambie demasiado. Y personalmente, como desarrollador, ¿cuánto peso le das al patrocinio corporativo de los proyectos? Por ejemplo, había varios proyectos de Vercel, pero STC, por ejemplo, no es un proyecto oficial de Vercel, solo es el chico de Vercel que lo está escribiendo, ¿verdad? ¿Importa para ti? ¿De dónde vienen estos proyectos? ¿O solo te basas en los méritos del propio proyecto? Creo que este es un punto muy importante, ¿cuánto respaldo hay detrás de él? Y sí, si solo un chico está tratando de reimplementar TypeScript, veo menos posibilidades de que tenga éxito que si una empresa paga a ingenieros para hacer algo grande. Es cierto. Es interesante, porque en el código abierto siempre hemos tenido este credo de que todos comienzan desde el mismo nivel, cualquiera puede crear la mejor herramienta para el futuro, pero es más difícil mantener algo si no tienes millones de dólares de inversión detrás de ello.