El Estado de las Herramientas de React

Rate this content
Bookmark
Slides

Las herramientas de construcción emergentes como Bun, ESBuild, SWC y Rome transformarán la forma en que trabajamos con React en el futuro. Veamos su estado actual, lo que se necesita para adoptarlas y predigamos cómo evolucionará el panorama.

29 min
02 Dec, 2022

Video Summary and Transcription

La charla discute más de 20 herramientas de JavaScript comúnmente utilizadas por los desarrolladores, incluyendo transpiladores y bundlers. Se destacan los pros y los contras de varias herramientas como Sucrase, Babel, SWC y ESBuild. También se menciona la importancia de TypeScript, los linters como eslint y la aparición de nuevas herramientas como Rome. La charla profundiza en el futuro de JavaScript, los desafíos de agrupar bibliotecas de UI y la era corporativa de las bibliotecas de JavaScript respaldadas por empresas.

Available in English

1. Introducción a las herramientas de JavaScript

Short description:

¡Hola Berlín! Mi nombre es Jonny Burger. Soy el mantenedor de ReMotion, un framework para hacer videos en React. Hablaré sobre más de 20 herramientas de JavaScript comúnmente utilizadas por los desarrolladores, organizadas en diferentes categorías. Vamos a repasarlas y daré mi opinión imparcial. Babel, el transpilador original, sigue siendo fundamental para React Native. SWC es el nuevo valor por defecto en Next.js y cuenta con el respaldo de la industria. ESBuild, el valor por defecto en Vite, es rápido y robusto, con un gran respaldo de la industria.

¡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.

2. Sucrase: Un Transpilador Rápido y Experimental

Short description:

Sucrase es un transpilador menos conocido que está escrito en TypeScript y es el más rápido. Sin embargo, tiene algunos problemas prácticos y no cumple completamente con las especificaciones. Se describe a sí mismo como experimental y divertido, pero puede producir archivos JavaScript inválidos.

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.

3. Transpiladores y Bundlers

Short description:

TypeScript se puede utilizar como un transpilador para generar archivos de definición .d.ts. Los frameworks o bundlers a menudo toman la decisión de qué transpilador utilizar. Webpack es el bundler más popular, pero Rollup es más rápido y prioriza los módulos ES. Sin embargo, no tiene reemplazo de módulo en caliente. Vite es un bundler popular que sirve archivos JavaScript directamente al navegador sin empaquetarlos. Parcel es un bundler más conservador que busca reducir la configuración y proporciona valores predeterminados rápidos como el transpilador SWC. Snowpack es el siguiente.

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.

4. JavaScript Tools Continued

Short description:

Vamos a saltarnos este. TurboPack, el sucesor de Webpack, cuenta con un gran respaldo de Vercel, pero carece de instrucciones de instalación y documentación completa. Dano, un tiempo de ejecución más rápido y seguro que admite TypeScript, no ha tenido una adopción significativa debido a problemas de compatibilidad. Sin embargo, Bunn, un nuevo tiempo de ejecución, tiene como objetivo ser más rápido que Node y compatible, ofreciendo la posibilidad de ejecutar código existente más rápido. En el ámbito de los linters, eslint se destaca con su extenso conjunto de reglas, incluidos los preajustes específicos del framework. Es importante destacar que eslint se someterá a una reescritura completa sin TypeScript.

Es posible que hayas oído hablar de ello, pero ya lo han descontinuado y ahora recomiendan Wheat.

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.

5. JavaScript Tools and Type Checkers

Short description:

Elección muy loca si me preguntas, y no entiendo por qué. Pero sin embargo, por supuesto, eslint, es imprescindible. Rome, un competidor escrito en Rust, es más rápido pero tiene menos reglas. Varios gestores de paquetes pueden introducir errores, así que usa core pack para especificar el gestor de paquetes para cada proyecto. Se recomienda encarecidamente TypeScript, y hay un nuevo comprobador de tipos basado en Rust llamado STC. Aún está en progreso y carece de un logotipo. Prettier es un formateador de código, JSON y markdown con opiniones.

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.

QnA

JavaScript Tools and AI Takeover

Short description:

Entonces Rome llega con la misma filosofía pero intenta ser más rápido y ofrece recuperación de errores. Las nuevas herramientas deben ser significativamente mejores o más rápidas para reemplazar las existentes. Una nueva herramienta, ChatGPT de OpenAI, escribe código perfecto y vuelve obsoletas a otras herramientas. Sígueme en Twitter y echa un vistazo a ReMotion. Comencemos con las preguntas y respuestas.

o sin punto y coma. Y también lo uso para formatear mi JSON y markdown. Tiene mucho soporte de lenguaje, pero no es tan rápido. Entonces Rome llega, nuevamente, con la misma filosofía, pero intenta ser más rápido, lo cual es, supongo, una buena idea. Y también ofrece recuperación de errores, lo que significa que si intentas formatear una sintaxis inválida, aún podría funcionar. Esta es una característica que Prettier no tiene y es bastante interesante. Entonces, ¿qué tienen en común todas estas categorías? Creo que si las nuevas herramientas quieren llegar y reemplazar a las que hemos estado usando hasta ahora, deben ser significativamente mejores o significativamente más rápidas. Si solo haces una mejora incremental, un poco mejor pero no cambia el juego, entonces vemos que las personas no están dispuestas a hacer el trabajo de migración para obtener estos pequeños beneficios. Realmente tiene que ser un cambio de juego y la compatibilidad también es muy importante. Lo vemos en Deno, por ejemplo, o en el nuevo linter que es rápido pero tiene muchas menos reglas, necesitamos poder aprovechar todo el trabajo que hemos hecho hasta ahora en nuestro ecosistema también en la nueva herramienta y no comenzar desde cero. Muy bien. Tuve que hablar más rápido porque llegó un recién llegado tardío. ¿Has visto esto? Es tan bueno. Salio hace dos días y casi lo consideraría un nuevo tipo de herramienta. Le pedí a ChatGPT de OpenAI que escribiera un componente React que promociona React Day Berlin. Y lo ves en Twitter todo el tiempo. Realmente es tan bueno. Escribe código perfecto, perfectamente formateado, sin errores. Completamente correcto y, por lo tanto, hace que todas las herramientas que he mencionado hasta ahora sean completamente obsoletas. E incluso como desarrolladores, todos nos quedaremos sin trabajo en poco tiempo. Y, sí, es triste que haya invertido todo este trabajo y ahora esta cosa de IA se esté apoderando. Así que debería dejar el escenario ahora. Puedes seguirme aquí en Twitter y también echar un vistazo a ReMotion, con el que puedes crear videos de forma programática. Muchas gracias. Muchas gracias, Johnny. ¿Por qué no te sientas aquí en el puesto de preguntas y respuestas y comenzamos con las preguntas? En primer lugar, tengo una pregunta personal. ¿Cuál es tu régimen de entrenamiento cardio para poder hablar tan rápido durante tanto tiempo? No creo que pueda hacer eso. Eso fue intenso. Estoy agotado. Necesito una pregunta más fácil.

Cheese, Vite, Yarn, Flow, and jQuery

Short description:

Comencemos con algo muy fácil. ¿Cuál es el mejor queso suizo y por qué es raclette? Oh, raclette es muy social. ¿Qué tan listo está Vite para producción? ¿Es algo que usarías, por ejemplo, en Remotion? ¿Es hora de abandonar yarn? Tenemos un viajero en el tiempo de 2018 que pregunta, ¿qué opinas de flow? Sí, ni siquiera merecía un lugar en la presentación, desafortunadamente. 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.

Muy bien, empecemos. Comencemos con algo muy fácil. ¿Cuál es el mejor queso suizo y por qué es raclette? Oh, raclette es muy social. Puedes sentarte alrededor de la mesa y tener queso derretido en el centro y automáticamente todos se divierten. Ojalá tuviéramos algo aquí ahora mismo. Muy bien, ahora pasemos a las preguntas serias. Déjame ver. ¿Qué tan listo está Vite para producción? ¿Es algo que usarías, por ejemplo, en Remotion? Sí, definitivamente. Creo que Vite también tiene alguna integración, algún middleware que podríamos usar para integrarlo en nuestro marco de trabajo y diría que lo estamos considerando. La historia de los módulos ES lo hace un poco más difícil para los usuarios y también, como mencioné, es solo un marco de trabajo de frontend, por lo que es más como un reemplazo de Create React app, pero menos para, por ejemplo, Next.js.

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é.

Bundling UI Libraries and the Future of JavaScript

Short description:

En el futuro, puede que no sea necesario empaquetar bibliotecas de interfaz de usuario. TypeScript se puede utilizar para transpilar y enviar la biblioteca a NPM. Se plantea la pregunta de por qué Denno no ha despegado como se esperaba, destacando los desafíos de hacer que todo funcione y la falta de beneficios significativos. Se discute la posibilidad de estandarizar diferentes variantes de JavaScript, alineándose con los estándares del navegador. El problema de la fatiga de JavaScript ha pasado del cliente y el tiempo de ejecución al lado de las herramientas. Actualmente, las opciones maduras y probadas en batalla son las claras ganadoras en el espacio de las herramientas. Se debate la importancia del patrocinio corporativo en los proyectos, considerando que el respaldo de una empresa aumenta las posibilidades de éxito.

Genial. Veamos, el mejor bundler y las herramientas para bibliotecas de kits de interfaz de usuario en 2023. Así que ahora tenemos a un viajero del tiempo desde el futuro. Diría que TypeScript. Quiero decir, si estás enviando una biblioteca de interfaz de usuario, no necesariamente tienes que empaquetarla, solo hace que sea más difícil cambiar las fuentes, parchear los módulos de node. Así que simplemente lo transpilaría con TypeScript y luego lo enviaría a NPM. Sí.

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.

The Corporate Era of JavaScript Libraries

Short description:

Ya sea que pierdas si nadie lo está usando o pierdas si todos lo están usando y te inundas de problemas. En los últimos años, hemos entrado en una era corporativa de bibliotecas de JavaScript patrocinadas por proveedores de alojamiento web. ¿Alguna vez lamentas los días en que el pequeño podía afectar el futuro de una manera más impactante? Sí, cualquiera todavía puede sembrar una semilla. Si tienes buenas ideas y las construyes, entonces... VerCell te contratará y podrás recibir un pago por hacerlo. Eso realmente puede sucederle a cualquier desarrollador aquí.

Pero creo que la realidad ahora es que simplemente tener un proyecto de código abierto y construirlo no escala. Ya sea que pierdas si nadie lo está usando o pierdas si todos lo están usando y te inundas de problemas. Siento que en los últimos años hemos entrado en esta especie de era corporativa de bibliotecas de JavaScript patrocinadas por proveedores de alojamiento web. Tienes a VerCell, tienes a Gatsby, Netlify, todas estas empresas. ¿Alguna vez lamentas los días en que el pequeño podía afectar el futuro de una manera mucho más impactante, o crees que todavía estamos allí? Sí, creo que cualquiera todavía puede sembrar una semilla. Si tienes buenas ideas y las construyes, entonces... VerCell te contratará y podrás recibir un pago por hacerlo. ¡Absolutamente! Y eso realmente puede sucederle a cualquier desarrollador aquí. Bien, vamos a hacer un par de preguntas más del público. Entonces, flujos de trabajo de monorepo como NX o Alerna. ¿Algún consejo cuando se trata de herramientas de construcción en ese entorno? Sí, también hay múltiples opciones disponibles. NX, Alerna y TurboRepo. Personalmente, uso TurboRepo. Gran marketing, ya sabes, soy un fanático de eso. Y anteriormente usaba Alerna, pero no tenía esta función de almacenamiento en caché que tiene TurboRepo. Y ahora uso TurboRepo. Desafortunadamente, no sé mucho sobre NX. Genial. Y luego la última pregunta, nos quedan unos 20 segundos en el reloj. ¿Qué hay del futuro de Remotion? No has dedicado mucho tiempo a promocionar tu producto, así que ¿por qué no nos cuentas qué estás construyendo? Sí, hasta ahora con Remotion nos hemos enfocado principalmente en permitir que los desarrolladores de React creen videos de forma programática. Lo que no fue tan bueno hasta ahora es que era muy difícil. Realmente tenías que ser un ingeniero experto en React para crear algo convincente. Y ahora solo queremos crear más plantillas, preajustes, abstracciones de nivel superior. Puedes imaginar esto como transiciones, efectos especiales, componentes de alto nivel que puedes agregar a Remotion para facilitar la creación de estos videos de forma programática ahora que se ha demostrado su viabilidad. Y también queremos brindarte herramientas para construir aplicaciones que puedan crear videos. Como una aplicación web donde un usuario puede arrastrar un video y tendrás una línea de tiempo y pueden editar un video en tu aplicación web y se renderizará en formato mp4 de manera muy sencilla y queremos facilitar eso. Maravilloso, me encanta el proyecto. Muchas gracias por estar aquí. Escuché que esta fue tu primera charla en una conferencia. Sí, así es. ¿Podemos aplaudir a Jony? ¡Gracias!.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn