¿Webpack en 5 años?

Rate this content
Bookmark

¿Qué podemos aprender de los últimos 10 años para los próximos 5 años? ¿Hay futuro para Webpack? ¿Qué necesitamos hacer ahora?

26 min
16 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

En los últimos 10 años, Webpack ha dado forma a la forma en que desarrollamos aplicaciones web al introducir la división de código, la colocación de hojas de estilo y activos junto con los módulos de JavaScript, y permitir el empaquetado para el procesamiento en el lado del servidor. La flexibilidad de Webpack y su amplio sistema de complementos también han contribuido a la innovación en el ecosistema. La configuración inicial de Webpack puede ser abrumadora, pero es necesaria debido a la complejidad de las aplicaciones web modernas. En aplicaciones a gran escala, hay problemas de rendimiento en Webpack debido a problemas con la recolección de basura, el aprovechamiento de múltiples CPUs y limitaciones arquitectónicas. Solucionar problemas en Webpack tiene sus compensaciones, pero una reescritura podría optimizar la arquitectura y solucionar problemas de rendimiento.

Available in English

1. Impacto y Futuro de Webpack

Short description:

En los últimos 10 años, Webpack ha dado forma a la forma en que desarrollamos aplicaciones web al introducir la división de código, la colocación de hojas de estilo y activos junto con los módulos de JavaScript, y permitir la agrupación para el procesamiento en el lado del servidor. La flexibilidad de Webpack y su amplio sistema de complementos también han contribuido a la innovación en el ecosistema. Si bien Webpack puede no ser el empaquetador más popular, sigue siendo una opción sólida en términos de estabilidad, flexibilidad y una amplia gama de casos de uso. Mirando hacia el futuro, es probable que Webpack siga siendo utilizado en proyectos existentes, pero los nuevos proyectos pueden tener otras opciones. Las lecciones aprendidas de los últimos 10 años de Webpack pueden guiar las futuras herramientas y mejoras. Sin embargo, debido a limitaciones de tiempo, no todas las lecciones se pueden abordar en esta charla, pero están disponibles en las diapositivas de la presentación.

Entonces, mi título es en realidad Webpack en Cinco Años, pero en realidad eso es solo un gancho, así que los atrapé. Hablaré sobre los últimos 10 años de Webpack y lo que podemos aprender para Webpack y para la comunidad en general y para el ecosistema sobre estos últimos 10 años. Qué errores cometimos, qué problemas tenemos y qué podemos hacer mejor.

Oh, vamos. Así que mi nombre es Tobias Koppers y creé Webpack en 2012, hace 10 años, así que lo he estado manteniendo durante 10 años y comencé a mantenerlo durante cinco años a tiempo parcial, como 10 horas por semana, y luego pasé a trabajar a tiempo completo en Webpack financiado por Open Collective, patrocinadores, donaciones y cosas así, y ahora trabajo y lo mantengo como parte de mi trabajo. También tengo dos hijos, de cinco y tres años, y vivo en Alemania en Baviera, así que cerca de aquí.

Así que 10 años de Webpack, creo que deberíamos celebrarlo y es en realidad un tiempo bastante largo para el ecosistema web, como 10 años, en años web es como cientos de años o algo así, y creo que podemos decir que al menos hemos dado forma al ecosistema un poco y trato de encontrar cuatro cosas que, creo, Webpack ha dado forma a la forma en que desarrollamos aplicaciones web. Entonces, una cosa, por qué comencé con Webpack fue agregar la división de código a los empaquetadores y la carga bajo demanda y creo que eso es algo que se ha establecido en la comunidad desde entonces y creo que está aquí para quedarse y hoy en día, todos los empaquetadores vienen con la división de código y la carga bajo demanda y casi todos están usando algo así. Otra cosa que promovimos o adoptamos es tener esta idea de combinar, colocar en el mismo lugar tus hojas de estilo, tus activos y otras cosas que no son JavaScript con tus módulos de JavaScript. Entonces, es como tener un gráfico de tu aplicación donde todo se importa entre sí y creo que eso también es algo que se mantendrá en la comunidad e incluso hay especificaciones involucradas como la especificación de módulos CSS y otras cosas que lo adoptan y lo mantienen en el ecosistema para siempre. Y otra cosa un poco más pequeña es que también aprendimos a usar empaquetadores o herramientas de preprocesamiento para el procesamiento en el lado del servidor o Node.js. Entonces, a menudo en una aplicación que utiliza Webpack y renderizado en el lado del servidor y cosas así, también empaquetamos nuestra aplicación en el lado del servidor, algo que no existía antes de Webpack, probablemente porque no lo necesitábamos, pero creo que eso también es algo que probablemente se mantendrá en la comunidad al menos por un tiempo y otra cosa más grande que creo que Webpack ha adoptado es la flexibilidad. Webpack comenzó de manera realmente flexible, con un gran sistema de complementos con enormes capacidades para extender, configurar y personalizar tu compilación y creo que eso es algo que realmente ha adoptado la innovación en el ecosistema y nuevas soluciones, nuevas ideas se pueden desarrollar combinadas con Webpack y también dan forma a nuevas ideas en el ecosistema. Así que creo que eso es bastante bueno. Pero hoy en día, Webpack no es el empaquetador más popular, hay herramientas más aburridas, tal vez la elección estable o la elección si ya tienes algo con Webpack, pero en el ecosistema de Twitter también, es un equipo de desarrollo basado en la moda, hay nuevos empaquetadores que surgen, o nuevas herramientas que no son de empaquetado que son bastante populares y hacen cosas buenas y probablemente todos tienen una característica que es mejor que algo en Webpack, y tal vez rendimiento u optimización o algo así, así que eso es más o menos lo que está de moda. Y aún así, creo que Webpack sigue siendo la elección sólida cuando quieres algo que sea realmente estable o realmente flexible y tal vez cubra muchos casos de uso, o tienes muchos complementos del ecosistema que quieres usar. Y en realidad, miré las descargas de NPM y Webpack sigue creciendo, así que no está en declive ni nada de eso, pero sí vemos que hay muchas cosas nuevas surgiendo en el ecosistema. Entonces, ¿cómo se ve el futuro para Webpack y para el ecosistema en general? ¿Se seguirá utilizando Webpack en cinco años? Creo que sí, al menos para proyectos existentes, porque las empresas y los equipos no cambian la pila tecnológica tan a menudo, es más como que usan cosas durante más años de los que podemos pensar. De hecho, todavía hay personas que usan Webpack 2, que tiene cinco años, y no les importa no actualizar cosas durante mucho tiempo, si funciona, y creo que se considera que funciona, al menos. Para nuevos proyectos, hay otra opción. No sé qué sucederá en cinco años. Podría ser que se desarrolle algo nuevo que podría ser mejor, o hay otras opciones obvias que se pueden usar y comenzar con nuevos proyectos. Qué sucederá en cinco años, no lo sé. Es un tiempo realmente largo en el ecosistema. Decidí recapitular sobre los últimos diez años de Webpack y ver qué lecciones podemos aprender de estos diez años, y qué podemos, puedo pensar qué podemos conservar de Webpack, diez años de Webpack para el ecosistema y para Webpack en general. Así que sí. También quiero decir qué podemos hacer ahora o qué podemos hacer en futuras herramientas sobre Webpack para solucionar estos problemas o mantener estas lecciones aprendidas. El problema es que hay tantas lecciones que recopilé preparando esta charla que en realidad no caben en esta charla. Es una conferencia híbrida, pero lo que hice fue preparar cientos de diapositivas para todas estas cosas y las mostré durante un segundo y el público remoto puede pausar la transmisión y leer todo esto y nos vemos en una hora después de discutir las más importantes con el público en vivo.

2. Configuración y Personalización de Webpack

Short description:

La configuración inicial de Webpack puede ser abrumadora, pero es necesaria debido a la complejidad de las aplicaciones web modernas. Adaptarse al ecosistema y tener valores predeterminados personalizables puede ayudar a mejorar la experiencia de desarrollo. La personalización es importante tanto para proyectos individuales como para el ecosistema en general, permitiendo la innovación y desbloqueando a los usuarios. Sin embargo, las opciones de personalización actuales en Webpack pueden ser confusas y la extensa API dificulta la iteración y el mantenimiento. Para abordar estos desafíos, sería beneficioso contar con un concepto de complemento simplificado y la inclusión de análisis para obtener comentarios de los usuarios. Además, el rendimiento es un área en la que Webpack se queda atrás de sus competidores debido a su uso de Node.js.

Entonces, el primero, configuraciones iniciales. Actualmente, la gente a menudo piensa que la configuración inicial que necesitas para comenzar con el proyecto es demasiado abrumadora, demasiado grande, demasiado material necesario, y en realidad no solía ser así en Webpack. Cuando Webpack comenzó, no necesitabas ninguna configuración, solo funcionaba con un simple comando de CLI, pero en realidad fue así hace cinco años, no desarrollábamos aplicaciones web tan complejas como ahora. Hoy en día, todos necesitan usar CSS, JavaScript, activos, quieren optimizar el procesamiento de imágenes, quieren un dialecto de JavaScript como TypeScript o quieren usar características de la etapa tres que necesitan ser transpiladas para versiones anteriores. Quieren integrar compiladores adicionales para su framework, como React que viene con la sintaxis JSX, Svelte que viene con un compilador diferente para compilar las plantillas, Angular que tiene un paso de preprocesamiento para las partes de producción. Vue también tiene estos geniales componentes individuales, componentes de un solo archivo que necesitan ser procesados. Entonces, se agregaron muchas herramientas a las aplicaciones web y Webpack no se adaptó un poco a eso, por lo que siguió teniendo valores predeterminados que no son realmente bajos y que se usan de esa manera. Entonces, ¿qué podemos hacer para solucionar eso? Los clics no son buenos. Creo que deberíamos ser más optimizados, tener valores predeterminados para que nos adaptemos al ecosistema. También creo que deberíamos reconocer el hecho de que estos valores predeterminados cambian con el tiempo, dentro de diez años, tal vez dentro de cinco años, probablemente tengamos valores predeterminados muy diferentes a los que tenemos ahora. Lo que creo que podemos hacer es tener algo, lo que algunas personas ya hacen, es tener preajustes que se versionan con las dependencias, para que podamos adaptarnos lentamente al ecosistema, pero también mantener bloqueado nuestro proyecto en una cierta versión de valores predeterminados sin tener muchos cambios disruptivos. Otro tema es la personalización. Creo que la personalización es realmente importante, y también es muy importante para el ecosistema, incluso si no lo estás usando directamente en tu proyecto, porque abraza este concepto de innovación del ecosistema donde puedes tener una idea genial y escribir un complemento para tu empaquetador y tus herramientas, y probarlo, tal vez publicarlo en npm y permitir que las personas lo usen, tal vez se convierta en el nuevo estándar en el que desarrollamos aplicaciones en el futuro. Pero también ayuda a desbloquear a los usuarios. Si estás luchando con algo que el empaquetador o tu herramienta no admite, entonces puedes modificarlo, escribir un complemento o personalizar la configuración para que se adapte a tu caso de uso, para que haga lo que necesitas, y así evitar quedarte atascado con el empaquetador y tal vez tener que cambiar porque no admite algo. También creo que ese fue un factor de éxito de Webpack en los primeros días, y tal vez también en la actualidad, que realmente tiene esta idea de flexibilidad y personalización y cosas así. Pero también es confuso en algunos aspectos, como que hay tres niveles de personalización. Tienes la configuración, los complementos, los cargadores. Es realmente complicado cuando tienes que usar la combinación de complemento y cargador con alguna configuración para hacer algo, así que puede ser confuso. Otra cosa es que la API, puedes extender todo en Webpack. Tienes acceso a todos los internos en Webpack. Eso es un problema porque no sabemos qué se está utilizando realmente. No podemos cambiar nada en nuestra API interna, y eso es realmente difícil para nosotros y también hace que sea fácil romper cosas porque podríamos cambiar los internos y eso es extraño. Sí. Entonces, ¿qué podemos hacer? ¿Qué podemos hacer? Creo que la idea es que no deberíamos tener este tipo de concepto de complemento. Creo que solo debería haber un tipo de complemento que tal vez tenga múltiples niveles de API. Como tener una API de bajo nivel y una API de alto nivel donde se pueda acceder a ambas API desde un solo complemento, y eso facilitaría su uso para las personas. También haría que la superficie de la API esté más limitada para exponer solo lo que realmente sabemos que es utilizado por los complementos y no exponer todos los internos, lo que dificulta nuestra iteración en los internos. Lo que también ayudaría, pero es realmente difícil de adoptar en las comunidades, es tener algún tipo de análisis donde realmente obtengamos comentarios de los usuarios, tal vez de forma automatizada o tal vez mediante una opción de participación o algo así, donde puedas informar qué API se utilizan realmente por los complementos para que podamos saber qué debemos mejorar o qué podemos eliminar o duplicar en el futuro. Entonces, otro tema realmente importante es el rendimiento. La mayoría de los competidores destacan en rendimiento porque están escritos en lenguajes nativos en comparación con Webpack, que utiliza Node.js.

3. Desafíos de rendimiento y arquitectura

Short description:

En aplicaciones a gran escala, hay problemas de rendimiento en Webpack debido a problemas con la recolección de basura, el aprovechamiento de múltiples CPUs y limitaciones arquitectónicas. Para abordar estos desafíos, sería beneficioso tener un procesamiento incremental y una arquitectura optimizada que se adapte al tamaño de la aplicación. Adoptar un enfoque de cálculo perezoso y garantizar compilaciones incrementales en diferentes entornos también puede mejorar el rendimiento. Sin embargo, es difícil solucionar estos problemas en Webpack sin romper el ecosistema y perder adopción. Se puede considerar la creación de un nuevo empaquetador con una arquitectura rediseñada, pero este enfoque tiene sus compensaciones y requeriría un esfuerzo significativo de migración.

Webpack es realmente malo en cuanto a rendimiento. No solía ser así. Hace diez años, nadie o casi nadie se quejaba del rendimiento y estaba bien. Pero al menos en aplicaciones a gran escala, hay problemas con el rendimiento debido a ciertas razones. Probablemente, el problema más problemático es que estamos luchando mucho con la recolección de basura debido a los grandes gráficos de modelos que crean muchos objetos, lo cual es malo, y el uso de JavaScript dificulta el aprovechamiento de múltiples CPUs para realizar cálculos. Pero también hay problemas arquitectónicos. Nuestra arquitectura está realmente diseñada para la flexibilidad. En cada compilación, construimos todo desde cero. Tenemos la mejor capacidad para complementos, la forma más fácil para que los complementos realicen sus cambios, pero esa no es la mejor arquitectura para el rendimiento. Sería mucho mejor tener algún tipo de procesamiento incremental, una arquitectura optimizada. Entonces, ¿qué necesitamos hacer, qué deberíamos hacer, pero es realmente difícil solucionar eso en Webpack? Sería mejor usar un lenguaje nativo para aprovechar múltiples CPUs y también comenzar con una arquitectura que tenga esta compilación incremental por diseño, es decir, que no dependa del tamaño de la aplicación. Esto también me lleva al siguiente punto que son las aplicaciones a gran escala. En realidad, las aplicaciones están cada vez más grandes y eso es un problema porque los problemas de rendimiento en Webpack se exponen realmente, ya que en Webpack es rápido para la compilación incremental, pero un poco lento a medida que escala con el tamaño de la aplicación, y eso se vuelve más grave a medida que la aplicación crece. Hay soluciones alternativas donde puedes dividir tus aplicaciones en múltiples aplicaciones pequeñas, o incluso algo como la compilación perezosa donde solo compilas en desarrollo lo que realmente estás usando. Eso ayuda, pero son soluciones alternativas, y si tuviéramos una arquitectura que se adaptara mejor a las aplicaciones de gran escala, lo que creo que deberíamos hacer es que la compilación perezosa sea la predeterminada para el futuro, es decir, todo debería ser calculado de forma perezosa y la pereza simplemente se adapta mejor a las aplicaciones grandes, porque probablemente no trabajas en toda la aplicación a la vez, sino en partes de ella, y si solo necesitas compilar esa parte, entonces el tamaño grande de la aplicación no se vuelve tan grave. Y sí, lo que siempre digo, deberíamos adoptar una arquitectura donde el rendimiento incremental no se escala con el tamaño de la aplicación, debería ser constante en todo momento y siempre debería ser rápido. Eso sería genial. También creo que si adoptamos cosas incrementales, también deberíamos adoptarlas en todas partes, como la compilación de producción debería ser incremental en CI, debería ser incremental, la compilación de desarrollo debería ser incremental, lo cual lo son, pero deberíamos ser incrementales en todas partes, y también deberíamos tener menos formas de optar por no ser incrementales, como si cambias los paréntesis, ¿por qué tiene que reiniciar la caché? Debería seguir siendo incremental. Eso sería genial. Y sí, ahora las diapositivas para la audiencia remota. No olvides pausar la transmisión. Vamos. Optimización, componentes del servidor y más cosas que podemos aprender de los últimos diez años de Webpack. Entonces, volvamos a las diapositivas. De acuerdo, estos problemas de rendimiento y arquitectura no se pueden cambiar realmente en Webpack. No podemos refactorizar toda la arquitectura y reescribir en un lenguaje nativo, eso rompería todos los complementos, todos los cargadores, todos los usuarios y tal vez todos los procesadores de estilo. Entonces, en realidad, tendría más sentido crear algo nuevo que tal vez se llame WhoopPack o

QnA

Trade-offs and Recommendations

Short description:

Solucionar problemas en Webpack tiene compensaciones. Una reescritura perdería el ecosistema y requeriría recuperar la adopción, mientras que solucionar problemas tiene el riesgo de romper a los usuarios. Sin embargo, una reescritura podría optimizar la arquitectura y solucionar problemas de rendimiento. Es difícil hacer una reescritura y llevaría años, mientras que solucionar problemas se puede hacer de forma incremental con beneficios directos para los usuarios. Existen compensaciones. En cuanto a las preguntas, se recomienda comenzar nuevos proyectos de React con Webpack para mayor estabilidad, pero depende de las preferencias personales. Webpack ofrece un gran ecosistema y soluciones preconstruidas para el desarrollo de React.

algo, y eso tendría esta nueva architecture. Pero hay compensaciones con eso, y voy a intentar resumirlo un poco. Entonces, ¿solucionar problemas, hacer una reescritura, tiene sentido? Cuando solucionamos los problemas, en realidad mantendríamos el ecosistema, la confianza y la adopción de Webpack, mientras que una reescritura perdería todo el ecosistema, los plugins y los loaders se perderían en esta reescritura, y necesitaríamos recuperar la adopción para Webpack, y sí, eso es difícil, y llevaría más de cinco años, probablemente, y también es difícil hacer una migración para que los usuarios migren a algo como Webpack. Sí. Pero por otro lado, no podemos solucionar todo en Webpack, lo que aprendimos, no podemos cambiar la arquitectura, no podemos limitar la superficie de la API, porque también rompería todo el Entonces, es imposible solucionar algunos problemas en el Webpack existente. Mientras que en una reescritura, podríamos optimizar nuestra arquitectura para compilaciones incrementales, podríamos solucionar estos problemas más profundos en el lado del rendimiento, pero ¿vale la pena? No lo sé. Esa es una buena pregunta. Sí, por otro lado, solucionar problemas también podría, como solucionar los problemas más grandes también tiene un poco de riesgo de romper a los usuarios, mientras que una reescritura rompería, como, a todos los usuarios, obviamente. En realidad, no rompería a los usuarios. Podrías seguir usando Webpack y migrar a Webpack más tarde, por lo que tiene sentido. También es difícil hacer una reescritura porque llevaría tal vez años reescribir todo. Tienes las mismas capacidades de Webpack mientras que al solucionar problemas en Webpack, se darían pasos más pequeños hacia el proceso y se obtendrían beneficios directos para los usuarios, y eso se puede hacer con un equipo más pequeño y la reescritura sería complicada. Así que, como siempre, hay compensaciones. Gracias. Supongo que tenemos algunas preguntas. Gracias. Para aquellos de ustedes que tienen preguntas, no olviden que pueden ir a slide.do e ingresar el código 1620 para hacer sus preguntas y luego yo se las puedo hacer a Tobias aquí mismo. Entonces, la primera pregunta es de Ro. ¿Recomendarías comenzar nuevos proyectos de React con Webpack y, si es así, por qué? Sí, lo recomendaría porque creé Webpack. Creo que es cuestión de preferencia, supongo. Entonces, Webpack es probablemente la elección sólida, una buena elección si quieres tener una opción estable. Puedes comenzar con otros paquetes. En realidad, no sé cuáles son las limitaciones de ellos. Así que podrías encontrarte con algo y son más nuevos, así que puedes comenzar con ellos. Y supongo que también siempre puedes comenzar con otra cosa y luego cambiar la pila más adelante. Así que es como tú quieras. La respuesta es, como dice un buen desarrollador, depende. Así que para las personas que quieran ir a la otra charla en la próxima pista. Pueden cambiar ahora porque vamos a comenzar en unos minutos. Y por supuesto, también pueden quedarse aquí. Y la siguiente pregunta también es de Rob, ¿por qué deberías usar React? ¿Por qué? ¿Por qué deberías usar Webpack como desarrollador de React? ¿Qué beneficios te brinda Webpack como desarrollador de React? Sí, tiene un gran ecosistema, y tienes soluciones preconstruidas para React. Así que

Getting Started and Future Improvements

Short description:

Webpack es fácil de comenzar y ha sido una tecnología probada durante muchos años. Aunque no hay una hoja de ruta oficial, el equipo trabaja continuamente para mejorar el ecosistema y abordar los desafíos de manera incremental. La financiación y los recursos limitados pueden ser un desafío, pero la comunidad de código abierto juega un papel crucial en el éxito del proyecto. Webpack está abierto a aprender y colaborar con otras herramientas de construcción en el ecosistema web. La sesión de preguntas y respuestas ha terminado, pero las discusiones adicionales pueden continuar en la sala de discusión de monetización de código abierto y en el salón de conferencias del ponente.

puedes comenzar con una plantilla o con herramientas que existen en el ecosistema. Es fácil comenzar con Webpack. Y también funciona bien, creo. Y solía funcionar bien durante unos cinco años más o menos. Así que supongo que es una buena elección y tiene sentido. Es una tecnología probada. Sí, tecnología probada. Muy bien. Una pregunta anónima. Las ideas para resolver los problemas de Webpack suenan geniales. ¿Existe una hoja de ruta para implementar actualmente esas soluciones y debemos esperar más mejoras en futuras versiones? Sí, no tenemos una hoja de ruta, una hoja de ruta oficial, así que es como si nunca hubiéramos tenido una. Es más bien que hacemos lo que creemos que es lo mejor actualmente para el ecosistema. Así que es como si estuviéramos tratando de mejorar esos problemas de manera incremental, y eso es básicamente una hoja de ruta. Y sí, resumí estos desafíos y problemas en la charla, y supongo que podemos solucionar algunos de estos problemas ahora mismo. Y muchos de ellos no son tan complicados de solucionar, como establecer valores predeterminados, es algo que podríamos hacer. Así que creo que eso va a suceder probablemente. Algún día pronto. Algún día pronto, sí. Pero no tenemos plazos, o nunca hemos tenido plazos para todo porque es como una gran presión, y no queremos tener este agobio. Es un proyecto de código abierto y la mayoría de los contribuyentes trabajan en su tiempo libre en eso. Así que no es algo para lo que queramos crear plazos y no es necesario tener plazos para nosotros. Es como-

Además de ti, ¿cuántas personas trabajan a tiempo completo en Webpack? Sí, no muchas. Son como dos personas que trabajan a tiempo completo en Webpack. Yo y alguien más. Pero es un poco problemático porque también tenemos menos financiación últimamente. Así que es como, es invierno para el ecosistema de JavaScript en su mayoría, y sí, podría ser un problema en el futuro que tengamos equipos pequeños para realizar mejoras más grandes. Sí, es extraño que básicamente 9 de cada 10 empresas utilicen Webpack y tengas que depender de las contribuciones de código abierto. Sí, ese es el problema. Así que creo que el código abierto tiene un momento muy difícil para obtener financiación y supongo que también hay una discusión al respecto hoy, así que siéntete libre de unirte a mí allí. Muy bien. Creo que vamos a hacer una última pregunta. La pregunta es de Thomas. ¿Dónde se ven ustedes en comparación con las nuevas herramientas de construcción que aprovechan las nuevas características del navegador, como feats? Creo que haremos algo para tomar decisiones similares. Así que en realidad, probablemente copiemos o robemos cosas de los nuevos paquetes, así que no es criminal. Creo que ese es el beneficio del ecosistema de código abierto, en realidad se te permite robar o copiar cosas. También creo que estas herramientas copiaron mucho de Webpack, así que no es que solo haya una forma. Creo más en un ecosistema, el ecosistema web, y todos nos beneficiamos de estos competidores y nos beneficiamos como ecosistema en su conjunto de estos desarrollos, nuevas ideas y nuevas tecnologías que surgen, de las cuales todos nos beneficiaremos. Sí, supongo que esa es una buena manera de hacerlo, tienes que compartir entre ustedes. Eso fue todo el tiempo que tenemos para preguntas y respuestas, si quieres continuar la conversación puedes ir a la sala de discusión de monetización de código abierto y ahora mismo puedes ir al salón de conferencias del ponente donde las personas también pueden continuar. Nos vemos allí. Gracias, Lotto Bias.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
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 Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
WorkshopFree
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.