¿Webpack en 5 años?

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

Vamos, vamos. Entonces, mi nombre es Tobias Koppers y creé Webpack en 2012, hace 10 años, así que lo mantengo durante 10 años y comencé a mantenerlo durante cinco años a tiempo parcial, como 10 horas por semana, y luego migré a trabajar a tiempo completo en Webpack financiado por Open Collective, patrocinadores, donaciones y cosas así, y ahora trabajo más de un año para 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 un poco.

Entonces, 10 años de Webpack, creo que deberíamos celebrarlo y en realidad es un tiempo bastante largo para el ecosistema web, como 10 años, en años web es como cientos de años o así, y creo que podemos decir que al menos moldeamos el ecosistema un poco y trato de encontrar cuatro cosas que, creo que Webpack moldeó la forma en que desarrollamos aplicaciones web. Entonces, una cosa, por qué comencé Webpack fue para agregar code splitting a los agrupadores y 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, cada bundler viene con code splitting y carga bajo demanda y casi todos están usando algo así. Otra cosa que promovimos o abrazamos es tener esta idea de combinar, co-localizar tus hojas de estilo, tus activos y tus otras cosas no-JavaScript con tus JavaScript modules. Entonces es como tener un gráfico de tu aplicación donde todo es importado por cada uno y creo que eso también es algo que se quedará en la comunidad e incluso las especificaciones involucradas como CSS modules spec y otras cosas que lo abrazan y lo mantienen en el ecosistema para siempre. Y otra cosa un poco más pequeña es que también aprendimos a usar agrupadores o herramientas de preprocesamiento para el procesamiento del lado del servidor o Node.js. Así que a menudo en una aplicación que usa Webpack y renderizado del lado del servidor y cosas así, entonces también agrupamos nuestra aplicación en el lado del servidor, eso es algo que no estaba allí antes de Webpack, probablemente porque no lo necesitábamos, pero creo que eso también es algo que probablemente se quedará en la comunidad al menos por un tiempo y otra cosa más grande que creo que Webpack abrazó es la flexibilidad. Webpack comenzó con una forma realmente flexible, un gran sistema de plugins con enormes habilidades para extender, configurar y personalizar tu construcción y creo que eso es algo que realmente abrazó la innovation en el ecosistema y nuevas soluciones, nuevas ideas pueden ser desarrolladas combinadas con Webpack y también moldea nuevas ideas en el ecosistema. Así que creo que eso está bastante bien. Pero hoy en día Webpack no es el Bundler más publicitado, es más como herramientas aburridas, quizás 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 publicidad, hay nuevos Bundlers que surgen, o nuevas herramientas no-agrupadoras que están bastante publicitadas y hacen cosas buenas, y probablemente todos tienen una característica que es mejor que algo en Webpack, y quizás performance o optimización o algo así, así que eso es bastante lo que se publicita tipo de cosas que están surgiendo. Y todavía creo que Webpack sigue siendo la elección sólida cuando quieres tener algo que es realmente estable o realmente flexible, y quizás cubre muchos casos de uso, o tienes muchos plugins del ecosistema que quieres usar. Y en realidad, miré las descargas de NPM, y Webpack sigue creciendo, así que no es que esté disminuyendo o algo que está sucediendo aquí, pero sí, vemos que hay muchas cosas nuevas que surgen 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, como, las empresas, los equipos, no cambian la pila tan a menudo, es más como que usan cosas durante más años de los que podemos pensar. En realidad, la gente todavía está usando Webpack 2, que tiene cinco años, y no les importa no actualizar cosas durante mucho tiempo, si está funcionando, y creo que está destinado a funcionar, al menos. Para nuevos proyectos, hay otra elección. No sé qué pasará en cinco años. Podría ser que se desarrolle algo nuevo que podría ser mejor, o hay otras opciones obvias que puedes usar y empezar con nuevos proyectos. Qué pasa en cinco años, no lo sé. Es un tiempo realmente largo en el ecosistema. Decidí hacer un resumen de los últimos diez años de Webpack y comprobar qué lecciones podemos aprender de estos diez años, y qué podemos, creo que podemos mantener de Webpack, diez años de Webpack para el ecosistema y para Webpack en general. Entonces, sí. También quiero decir qué podemos hacer ahora o qué podemos hacer en futuras herramientas en Webpack para solucionar estos problemas o para mantener estas lecciones aprendidas. El problema es que hay tantas lecciones que recogí 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 todo esto y las mostré un segundo y la audiencia remota puede pausar la transmisión y leer todo esto y nos vemos en una hora después de discutir los más importantes con la audiencia en vivo.

Entonces, el primero, configuraciones iniciales. Actualmente, la gente a menudo piensa que la configuración inicial que necesitas para empezar con el proyecto es demasiado abrumadora, demasiado grande, demasiadas cosas necesarias, y en realidad no solía ser así en Webpack. Cuando Webpack empezó, no necesitabas ninguna configuración, simplemente funcionaba con un simple comando CLI, pero en realidad fue que hace cinco años, no desarrollábamos aplicaciones web tan complejas. Como hoy en día todo el mundo necesita usar CSS, JavaScript, activos, quieren procesar la optimización de imágenes, quieren un dialecto de JavaScript como TypeScript o quieren usar características de la etapa tres que necesitan ser transpiladas para navegadores más antiguos. Quieren integrar compiladores extra para su framework como React viene con sintaxis JSX, Svelte viene con un compilador diferente para compilar las plantillas, Angular tiene como un paso de preprocesamiento para los bits de producción. Vue también tiene estos geniales componentes de un solo archivo que necesitan ser procesados. Así que se añadió un montón de herramientas a las aplicaciones web y Webpack no se adaptó a eso un poco así que siguió teniendo realmente bajos valores predeterminados que se usan de esa manera. Entonces, ¿qué podemos hacer para arreglar eso? El clicker no es bueno. Así que creo que deberíamos estar más optimizados, en tener valores predeterminados así que deberíamos adaptarnos con el ecosistema. También creo que deberíamos reconocer el hecho de que estos valores predeterminados cambian con el tiempo, como dentro de diez años, quizás dentro de cinco años, probablemente tengamos valores predeterminados muy diferentes a los que tenemos ahora. Lo que creo que podemos hacer es como tener algo, lo que algunas personas ya hacen, es tener presets que están versionados con dependencias, así que podemos adaptarnos lentamente con el ecosistema, pero también mantener tu proyecto bloqueado en una cierta versión de valores predeterminados sin tener muchos cambios importantes. Otro tema es la personalización. Así que creo que la personalización es realmente importante, y también realmente importante para el ecosistema, incluso si no lo estás usando directamente para tu proyecto, porque abraza este concepto de innovación del ecosistema donde puedes mirar, como si tienes una idea genial y puedes escribir un plugin para tu bundler y para tu herramienta, y, como, probarlo, quizás publicarlo en npm, y dejar que la gente lo use, quizás se convierta en el nuevo estándar que desarrollamos aplicaciones en el futuro. Pero también ayuda a desbloquear a los usuarios. Si estás luchando con algo que el Bundler no soporta, o tu herramienta no soporta, entonces puedes realmente entrar a modificar, escribir un plugin, o personalizar la configuración para, como, tener tu uso caso, como, haciendo lo que haces, y realmente te quedas atascado con el Bundler, y quizás tienes que cambiar porque no soporta algo. También creo que fue uno de los factores de éxito de Webpack en los primeros días, y quizás también hoy en día que realmente tiene esta idea de flexibilidad y personalización y cosas así. Y, pero también es confuso en algunas cosas, como, hay tres niveles de personalización. Tienes configuración, tienes plugins, tienes cargadores. Es realmente complicado cuando tienes que usar la combinación de plugin y cargador con alguna configuración para hacer algo, así que puede ser confuso. Otra cosa es que la API es, puedes extender todo en Webpack. Tienes acceso a todos los internos en Webpack. Eso es un problema porque no sabemos qué se usa realmente. No podemos cambiar nada en nuestra API interna, y eso es realmente difícil para nosotros y también como hace fácil romper cosas porque podría cambiar internos y eso es raro. Sí. Entonces, ¿qué podemos hacer? Entonces, ¿qué podemos hacer? Creo que la idea es que no deberíamos tener este tipo de concepto de plugin. Creo que debería haber sólo un tipo de plugin que quizás tenga varios niveles de APIs. Como tienes como una API de bajo nivel y una API de alto nivel donde puedes acceder a ambas de estas APIs desde un solo plugin y eso haría más fácil para la gente usarlo. También hace la superficie de la API más restringida para exponer sólo lo que realmente sabemos que es usado por los plugins y no exponer todos los internos que hace difícil para nosotros iterar en los internos. Lo que también ayudaría, pero es realmente difícil de abrazar en las comunidades como tener algunas analíticas donde realmente obtenemos retroalimentación del usuario, quizás automatizada o quizás por optar por algo así, donde puedes informar cuáles son las APIs realmente utilizadas por los plugins para que sepamos qué deberíamos mejorar o qué podemos soltar o duplicar en el futuro. Entonces, otro tema realmente grande es el rendimiento. Así que como la mayoría de los competidores sobresalen en el rendimiento porque están escritos en lenguajes nativos y comparados con Webpack, que es Node.js,

Webpack es realmente malo en performance. No solía ser así. Hace diez años, nadie o menos personas se quejaban del performance y estaba bien. Pero al menos en mayor scale hay problemas con el performance por varias razones. Probablemente lo más problemático es que luchamos mucho con la recolección de basura debido a los grandes gráficos de modelos que crean muchos objetos y eso es malo y usar Javascript dificulta el aprovechamiento de múltiples CPUs para hacer cálculos. Pero también hay problemas arquitectónicos. Nuestra architecture está realmente construida para la flexibilidad. En cada compilación construimos todo desde el principio. Tenemos la mejor capacidad para los plugins, la forma más fácil para que los plugins hagan sus cambios pero esa no es la mejor architecture para el performance. Sería realmente mejor tener algún tipo de procesamiento incremental, arquitectura optimizada. Entonces, lo que necesitamos hacer, lo que deberíamos hacer, pero es realmente difícil solucionar eso en Webpack sería mejor si usáramos un lenguaje nativo, para que podamos aprovechar múltiples CPUs y también empezar con una architecture que tenga esta compilación incremental por design, como no depender del tamaño de la aplicación. Esto también me lleva al siguiente punto que son las aplicaciones de gran escala. Como, en realidad las aplicaciones se hacen cada vez más grandes y eso es un problema porque los problemas de performance en Webpack se exponen realmente, porque en Webpack, es bastante rápido para la compilación incremental, pero un poco, escala por el tamaño de la aplicación y eso se vuelve más serio cuando la aplicación crece, y 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 architecture que escalaría con las aplicaciones de una mejor manera. Lo que creo que deberíamos hacer es, como, perezoso debe ser el predeterminado para el futuro, como todo debería ser calculado perezosamente y perezoso simplemente escala mejor con aplicaciones grandes, porque entonces probablemente no trabajas en toda la aplicación a la vez, como trabajamos en partes de eso, y si solo necesitas compilar esa parte, entonces la gran escala de la aplicación no se vuelve tan seria. Y, sí, lo que siempre digo, deberíamos adoptar una architecture donde el rendimiento incremental no scale con el tamaño de la aplicación, debería ser constante en todo esto, y debería ser siempre rápido. Eso sería genial. También creo que, como, si adoptamos cosas incrementales, deberíamos también 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, que 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 tú cambias los paréntesis, ¿por qué tiene que restablecer 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 de servidor, y más cosas que podemos aprender de los últimos diez años de Webpack. Entonces, volvamos a las diapositivas. Bueno, estos problemas con el performance y la architecture, realmente no podemos cambiar eso en Webpack. No podemos refactorizar toda la architecture y reescribir en el lenguaje nativo que rompería cada plugin, cada cargador, cada usuario, y tal vez cada procesador en estilo y cosas así. Entonces, en realidad tendría más sentido crear algo nuevo que tal vez sea WhoopPack o

algo, y eso tendría esta nueva architecture. Pero hay compensaciones con eso, y yo trato de resumirlo un poco. Entonces, ¿qué arreglar problemas, tenemos una reescritura, tiene sentido? Entonces, cuando arreglamos los problemas, realmente mantendríamos el ecosystem, la confianza y la adopción de Webpack, mientras que una reescritura perdería todo el ecosystem, los plugins y cargadores se perderían en esta reescritura, y necesitaríamos recuperar la adopción para Webpack, y, sí, eso es difícil, y probablemente tomaría más de cinco años, y es también difícil hacer una migración para que los usuarios migren a algo como Webpack. Sí. Pero por otro lado, no podemos arreglar todo en Webpack, lo que aprendimos, no podemos cambiar la architecture, no podemos limitar la superficie de la API, porque también rompería todos los Entonces, es imposible solucionar algunos problemas en el Webpack existente. Mientras que en la reescritura, podríamos optimizar nuestra architecture para compilaciones incrementales, podríamos solucionar estos problemas más profundos en el lado del performance, pero ¿vale la pena? No lo sé. Esa es una buena pregunta. Sí, por otro lado, como, arreglar problemas también podría, como, arreglar los problemas más grandes también tiene un poco de riesgo de romper a los usuarios mientras que reescribir 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, así que tiene sentido. También es difícil hacer una reescritura porque tomaría como años reescribir todo. Tienes como las mismas habilidades de Webpack mientras que en la solución de problemas en Webpack, haría pasos más pequeños hacia el proceso y como beneficios directos para los usuarios y eso también puede hacerse con un equipo más pequeño y reescribir sería complicado. Así que compensaciones, como siempre. Así que gracias. ¿Supongo que tenemos algunas preguntas? Gracias. Entonces, para aquellos de ustedes que tienen preguntas, no olviden que pueden ir a slide.do e ingresar el code 1620 para hacer sus preguntas y luego yo puedo preguntarlas a Tobias aquí mismo. Entonces, la primera pregunta es de Ro. ¿Recomendarías empezar nuevos proyectos de React con Webpack y si sí, por qué? Sí, lo recomendaría porque creé Webpack. Creo que es cuestión de sabor, supongo. Así que Webpack es probablemente la elección sólida, una buena elección si quieres tener una elección estable. Puedes empezar con otros bundles. En realidad no sé cuáles son las limitaciones de ellos. Así que podrías encontrarte con algo y son más jóvenes, así que puedes empezar con ellos. Y supongo que también puedes empezar con algo más y luego cambiar el stack más tarde. Así que es como fee-fee. Entonces, la respuesta es, como dice un buen desarrollador, depende. Así que para las personas que quieren ir a la otra pista para la próxima charla. Puedes cambiar ahora porque vamos a empezar eso en unos minutos. Y por supuesto puedes quedarte aquí también. Y la siguiente pregunta es de Rob también, ¿por qué deberías usar React? ¿Por qué? ¿Por qué deberías usar Webpack como desarrollador de React? ¿Qué beneficio te aporta Webpack como desarrollador de React? Sí, tiene mucho ecosystem, y tienes grandes soluciones preconstruidas para React. Así que

puedes simplemente comenzar con una plantilla o con herramientas que existen en el ecosystem. Es fácil empezar con Webpack. Y también funciona bien, creo. Y solía funcionar bien durante como cinco años o así. 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 solucionar los problemas de Webpack suenan geniales. ¿Existe un plan para implementarlas actualmente, y deberíamos esperar más mejoras en las futuras versiones? Sí, no tenemos un plan, un plan oficial, así que nunca hemos tenido uno. Es más como que hacemos lo que creemos que es actualmente lo mejor para el ecosystem. Así que es como si estuviéramos tratando de mejorar esos problemas de manera incremental, y eso es básicamente un plan. 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 hacer los 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 muchos, 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 necesitamos tener plazos para nosotros. Es como-

Entonces, aparte de ti, ¿cuántas personas trabajan a tiempo completo en Webpack? Sí, no muchas. Son como dos personas trabajando a tiempo completo en Webpack. Así que yo y alguien más. Pero es un poco problemático porque también tenemos menos financiación últimamente. Así que es como, es el invierno para el ecosystem de JavaScript en su mayoría, y sí podría ser un problema en el futuro que tengamos equipos demasiado pequeños para hacer mejoras más grandes. Sí, es extraño que básicamente 9 de cada 10 empresas funcionen con Webpack y tengan que funcionar desde el espacio de contribución de código abierto. Sí, ese es el problema. Así que creo que el código abierto tiene realmente dificultades para conseguir financiación y supongo que también hay una discussion sobre eso 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 te ves 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, probablemente copiaremos o robaremos cosas de los nuevos bundles, así que no es delito. Creo que esa es la ventaja del ecosystem de open-source, en realidad se te permite robar o copiar cosas. También creo que estas herramientas copiaron mucho de Webpack así que no es que haya solo una forma. Creo más bien en un ecosystem, el ecosystem web, y todos nos beneficiamos de estos competidores y nos beneficiamos como ecosystem en su conjunto de estos desarrollos e ideas nuevas y nuevas tecnologías emergen, todos nos beneficiaremos de ellas. Sí, supongo que esa es una buena forma de hacerlo, tienes que compartir entre todos. 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 sobre la monetización del código abierto y ahora mismo vas a ir al salón de los oradores donde la gente también puede continuar. Nos vemos allí. Gracias, Lotto Bias.