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,
Comments