Panel Discussion: Next Gen Build Tools

Hola, estoy muy feliz de estar aquí y de estar con el equipo de Git Nation nuevamente en este excelente evento de JS Nation y estoy aún más privilegiado y honrado de estar aquí con este excelente panel de expertos. Evan Yeo, creador de Vue.js y Vite, no estaba seguro de eso. Sí, por eso pregunté. Supuse que podría ser francés, pero luego, ya sabes, el estadounidense en mí no estaba 100% seguro. Sean, también conocido como Suik Suang, jefe de experiencia de desarrollador en Temporal I.O y autor de Coding Career Handbook, di hola. Hola, hola, hola. Y Fred K. Schott, autor de Snowpack y que aparentemente tuvo un lanzamiento muy emocionante ayer, justo ayer. Sí, justo ayer. Bien por ti, felicitaciones. Y también justo después de los Premios de Código Abierto, que son muy importantes para mí, como líder de la comunidad IEL de Nube Nativa y Código Abierto así que eso es emocionante. Felicitaciones a todos los ganadores. Estoy realmente emocionado de estar aquí. Creo que esta va a ser una sesión realmente genial. Así que, amigos, no olviden dejar sus preguntas para nuestros panelistas. Están aquí ahora con nosotros y realmente quieren escuchar sus opiniones expertas sobre herramientas de construcción de nueva generación. Así que supongo que la pregunta del millón para todos ustedes y que cada uno de ustedes primero se presente o nos dé un poco de contexto sobre por qué saben mucho sobre herramientas de construcción de nueva generación, pero también qué hace que una herramienta sea una herramienta de construcción de nueva generación en comparación con una herramienta de construcción antigua regular. Así que comencemos con Evan. Claro. Soy Evan. Trabajo en Vue.js y Vite. Y supongo que Vite se considera una herramienta de construcción de nueva generación. Ese es un poco el eslogan. Pero, honestamente, si me preguntaran cómo definir qué realmente lo hace de nueva generación, no creo que haya una línea muy clara o definitiva.

Creo que las herramientas de generación anterior, llamadas así, como Webpack, dado un rediseño o mejoras adecuadas, pueden incorporar algunas de las características de las herramientas de nueva generación. Así que no creo que sea algo muy definitivo como esto siempre va a ser viejo, esto siempre va a ser nuevo, ¿verdad? En términos de tecnología, siempre va a ser un paisaje cambiante. Pero supongo que, en general, creo que algunas de las tendencias que he estado viendo personalmente son la adopción de estos nuevos estándares emergentes, aprovechando de la plataforma misma, como módulos nativos de ES, importaciones dinámicas nativas. Hay cosas interesantes que están sucediendo en este organismo de estándares, como nueva URL o import meta, como import.meta a URL, puedes usar eso.

Hola, estoy muy feliz de estar aquí y de estar nuevamente con el equipo de Git Nation y este excelente evento de JS Nation y me siento aún más privilegiado y honrado de estar aquí con este excelente panel de expertos. Evan Yeo, creador de Vue.js y Vite, no estaba seguro de eso. Sí, por eso pregunté. Supuse que podría ser francés, pero ya sabes, el estadounidense en mí no estaba 100% seguro. Sean, también conocido como Suik Suang, jefe de experiencia de desarrollador en Temporal I.O y autor de Coding Career Handbook, saluda. Hola, hola, hola. Y Fred K. Schott, autor de Snowpack y que aparentemente tuvo un lanzamiento muy emocionante ayer, justo ayer. Sí, justo ayer. Bien por ti, felicitaciones. Y también justo después de los Premios de Código Abierto, que son muy importantes para mí, como líder de la comunidad IEL de Cloud Native y Open Source así que eso es emocionante. Felicitaciones a todos los ganadores. Estoy realmente emocionado de estar aquí. Creo que esta va a ser una sesión realmente genial.

Así que, amigos, no olviden dejar sus preguntas para nuestros panelistas. Están aquí ahora con nosotros y realmente quieren escuchar sus opiniones expertas sobre herramientas de construcción de próxima generación. Así que supongo que la pregunta del millón de dólares para todos ustedes y dejemos que cada uno de ustedes primero se presente o nos dé un poco de contexto sobre por qué saben mucho sobre herramientas de construcción de próxima generación, pero también qué hace que una herramienta sea una herramienta de construcción de próxima generación en lugar de solo una herramienta de construcción antigua. Así que empecemos con Evan. Claro. Soy Evan. Trabajo en Vue.js y Vite. Y supongo que Vite se considera una herramienta de construcción de próxima generación. Ese es un poco el eslogan. Pero, honestamente, si me preguntaran cómo definir qué realmente la hace de próxima generación, no creo que haya una línea muy clara o definitiva. Creo que las herramientas existentes llamadas de generación antigua como Webpack, dado un rediseño adecuado o mejoras, pueden incorporar algunas de las características de las herramientas de próxima generación. Así que no creo que sea algo muy definitivo como esto siempre va a ser viejo, esto siempre va a ser nuevo, ¿verdad? En términos de tecnología, siempre va a ser un paisaje cambiante. Pero supongo que, en general, creo que algunas de las tendencias que personalmente he estado viendo son la adopción de estos nuevos estándares emergentes, aprovechando de la plataforma misma, como módulos nativos VS, importaciones dinámicas nativas. Hay cosas interesantes que están sucediendo en este organismo de estándares, como nueva URL o import meta, como import punto meta a URL, puedes usar eso. Y también como, creo que hay un trabajo en curso tratando de estandarizar las importaciones de CSS también. Así que hay mucha cosas interesantes allí.

creo que hay un trabajo en curso tratando de estandarizar las importaciones de CSS también. Así que hay muchas cosas interesantes allí. Creo que las herramientas de nueva generación en general intentan alinearse con estos estándares nativos que están surgiendo y tratar de aprovechar tantas capacidades nativas como sea posible. Y otro aspecto es que, supongo, las herramientas de nueva generación no se limitan realmente a ser estrictamente JavaScript, como mientras sirvas el propósito de una herramienta de construcción, podemos aprovechar herramientas, herramientas de nivel inferior escritas en otros lenguajes o la herramienta en sí puede escribirse en otros lenguajes además de JavaScript. Eso es solo mi opinión.

Es más seguro con tipos. A veces es más seguro. Es poliglota como Evan ya dijo. Tengo este sueño de llamarlo esencialmente núcleo de scripting, lo siento, shell de scripting y núcleo de sistemas. Eso es mucho de lo que la gente también está moviéndose hacia. Y luego algún tipo de JavaScript isomórfico que viene en forma de cosas como Astro, en lo que Fred también está trabajando. Así que hay un montón de ideas todas lanzadas ahí. No hay un tema general aparte de, estos son solo más nuevos y no se han trabajado antes. Así que si quieres llamar a una línea de, como, nueva generación, creo que estas son las direcciones que la gente está explorando. Interesante. Mencionaste a Rome, así que lo tendremos en cuenta porque eso va a ser una de las próximas cosas de las que vamos a hablar. Pero quiero dejar que Fred también responda a la pregunta.

Así que primero, Fred, preséntate y también danos tu pequeña opinión sobre qué es un filtro FGen. Sí, definitivamente. Quiero decir, todavía me estoy riendo de Sean, periodista de JavaScript. Eso es solo, nunca he tenido un título para lo que eres, pero eso es realmente acertado. No, quiero decir, esa publicación de blog captura donde vimos nuestra visión. Así que he estado trabajando en un proyecto llamado Snowpack durante un tiempo. Y antes de eso, algo llamado ES Install. Y ahora el lanzamiento de ayer fue algo llamado Astro. Y todo esto ha sido sobre explorar el espacio de lo que es una herramienta de construcción de nueva generación. Y cuando comenzamos, era un poco mucho de lo que ya se ha dicho, ¿verdad? Hay este verdadero cambio hacia usar más cosas en el navegador, JavaScript nativo del navegador, y depender menos de todas las herramientas que puedes, que era un poco para dar un resumen dramático de dónde veníamos durante la última década. Era como, webpack hará todo.

Y así, ha habido un verdadero movimiento hacia otras herramientas para resolver el empaquetado usando más lenguajes compilados y WASM. No creo que ninguna de estas herramientas sería la mitad de impresionantes como lo son si no pudiéramos descansar sobre los hombros de ES Build y SWC. Así que, un gran saludo a ellos. Ellos están impulsando mucho de esto a nivel más bajo. Y luego, sí, solo como dejar que el navegador se ponga al día durante la última década. Ahora podemos depender de estos realmente geniales primitivos nativos en el navegador, lo que simplemente reduce la cantidad de trabajo que necesitas hacer como desarrollador, lo que tu herramienta necesita hacer, y obtienes una base de herramientas mucho más simple como resultado. Eso es realmente interesante.

Está bien. Eso es muy útil. Swix, te dejaré continuar desde aquí, cuéntanos un poco sobre ti y lo que consideras que es una herramienta de construcción de nueva generación. Sí. Siento el síndrome del impostor aquí porque en realidad no trabajo en una herramienta de nueva generación. Más o menos cumplo el papel de periodista de JavaScript. Así que escribo sobre estas herramientas y las pruebo en lugar de construir una realmente.

Así que mucho respeto a los otros dos que están aquí. De hecho, creo que la única razón por la que estoy aquí es porque escribí esta publicación de blog sobre la tercera era de JavaScript, de la que creo que Fred también va a hablar. Así que tenía algunas definiciones. Son módulos ES primero. Están colapsando capas. A veces solíamos tener esta filosofía de Unix en JavaScript donde cada herramienta hace una pequeña parte de la cadena de herramientas, puedes ver una consolidación de trabajos en una sola herramienta, que es parcialmente lo que hacen las herramientas de Rome. Es más seguro en términos de tipos. A veces es más seguro. Es poliglota como ya dijo Evan. Tengo este sueño de llamarlo esencialmente núcleo de scripting, lo siento, shell de scripting y núcleo de sistemas. Eso es mucho de lo que la gente también está moviéndose. Y luego algún tipo de JavaScript isomórfico que viene en forma de cosas como Astro, en lo que Fred también está trabajando. Así que hay un montón de ideas lanzadas allí.

No hay un tema general aparte de que, estas son solo más nuevas y no se han trabajado antes. Así que si quieres llamar a una línea de, como, nueva generación, creo que estas son las direcciones que la gente está explorando. Interesante. Mencionaste a Rome, así que lo tendremos en cuenta porque eso es lo que será una de las próximas cosas de las que hablaremos. Pero quiero dejar que Fred también responda a la pregunta. Así que primero, Fred, preséntate y también danos tu opinión sobre lo que es un filtro FGen. Sí, definitivamente. Quiero decir, todavía me estoy riendo de Sean, periodista de JavaScript. Eso es simplemente, nunca he tenido un título para lo que eres, pero eso es realmente acertado. No, quiero decir, esa publicación de blog clava donde vimos nuestra visión. Así que he estado trabajando en un proyecto llamado Snowpack durante un tiempo.

Así que, me gusta la comparación con herramientas más antiguas, pero dado que lo mencionaste brevemente, te dejaré desglosar eso, irónicamente, y cuéntanos un poco sobre las diferencias, ¿verdad? Entonces, lo que estabas usando hasta ahora, y lo que ha mejorado significativamente ahora que puedes adoptar herramientas de construcción de nueva generación? Sí, claro. Así que, podría ser el más tipo de viejo gritando a las nubes en esto porque nosotros comenzamos a mirar esto tan temprano cuando era solo un espacio dominado por web-pack, y ahora hay un montón más de opciones. Pero en ese momento, esto fue de vuelta en 2018, 2019, simplemente no podías importar React en el navegador. Tenías que básicamente usar un empaquetador o usar la construcción UMD, lo que significa que eres como window.reactdm y window.reactdomin, y haciendo este enfoque más manual, realmente no tenía la misma conveniencia de que tú vas a un web-pack y realmente puedes usar ESM, y puedes usar una sintaxis que se siente realmente moderna y fresca. Pero detrás de escena, web-pack estaba como tomando eso y haciendo mucho trabajo para empaquetarlo por ti para que funcionara en un navegador que tal vez no tenía ese primitivo, esa sintaxis de importación-exportación. Y así, muchos de mis primeros días fueron como, no, no necesitas hacer todo esto, pero fue solo porque estos primitivos estaban ahora finalmente en el navegador. Y así, sí, dominaron la última década porque era realmente la única forma de obtener una experiencia de desarrollador moderna que realmente funcionara en todos los navegadores. Pero lo que hemos visto ahora que tenemos estos primitivos es que algunas de las comprensiones básicas de lo que es una DevTool están siendo revisitadas. Así que la idea de tener que volver a empaquetar tu sitio cada vez que guardas, o ejecutar un montón de procesamiento en grandes partes de tu sitio durante el desarrollo, esas están siendo revisitadas, y muchas de ellas están desapareciendo a favor de lo que V8 y Snowpack hacen, que es tratar tus archivos individuales como construcciones individuales y no necesariamente tener que, oh, Evan, no quiero hablar por ti, creo que Snowpack podría ir un poco más dramáticamente en esta dirección, pero pensando incluso en el empaquetador como una herramienta opcional en tu cadena de herramientas. Y si no necesitas empaquetar, no te importa eso, no tienes que, puedes traerlo cuando quieras ir cuando estés listo para abordar el rendimiento o para ir a producción. Así que todas estas cosas fundamentales sobre cómo construimos sitios web están siendo revisitadas por primera vez en un tiempo. Es un momento realmente emocionante.

Sí, suena emocionante. Evan, te permitiré intervenir aquí y contarnos un poco sobre cómo V8 es diferente, en qué se está enfocando V8, qué hay en la hoja de ruta en términos de llevarlo hacia adelante como una herramienta de construcción de nueva generación. Claro. Así que para mí, V8 comenzó realmente con la necesidad que tengo para mí mismo porque construimos Vue CLI, que está basado en webpack. Y cuando construí Vue CLI, teníamos este tipo de comando menos conocido llamado VueServe, que es un comando global que simplemente te permite iniciar un servidor de desarrollo para un archivo Vue sin ninguna configuración en absoluto. Solo necesitas un archivo, y puedes usar ese comando para iniciar un servidor de desarrollo. Y me gusta eso, pero con el tiempo, sigue siendo que, para hacerlo, tienes que instalar Vue CLI globalmente, y todo el proceso sigue siendo más lento de lo que hubiera esperado. Siempre quise tener esta cosa donde literalmente puedo iniciar un servidor de desarrollo en milisegundos y tener algo en la pantalla de inmediato. Cuando vi que los navegadores comenzaron a implementar importaciones nativas de ES en el navegador, y estaba jugando con eso, y pude realmente compilar un archivo Vue al vuelo en la solicitud, y tenía esa prueba de concepto, pero en ese momento, realmente era solo una prueba de concepto, porque en ese momento, muy pocas personas realmente usaban importaciones nativas de ES, y pensé, tal vez esto es solo demasiado temprano, pero un año o dos después, me di cuenta, oh, todos los navegadores principales hoy en día realmente vienen con importaciones nativas de ES. Tal vez es hora de revisar esa idea, pero al mismo tiempo, estaba tratando de averiguar cómo funcionaría el reemplazo de módulos en caliente sobre eso, porque eso se está convirtiendo en algo que es esencial para flujos de trabajo a gran escala. Y revisité el proyecto, finalmente descubrí cómo hacer el reemplazo de módulos en caliente con módulos nativos de ES, y esa fue como la forma inicial, cómo Veed tomó forma. Y me di cuenta de que esto podría ser más que solo una herramienta de prototipado, así que a un nivel más alto, Veed está construido sobre eso y estamos tratando de realmente, creo que el objetivo inicial era proporcionar algo más cercano en experiencia de desarrollo a Vue CLI, porque queremos tener un equivalente más ligero, más ágil y moderno a Vue CLI para nuestros usuarios. Pero a lo largo del camino, a medida que construimos más y más características, como mover las características equivalentes a Veeds, nos damos cuenta de que muchas de ellas no son específicas de Vue, en realidad pueden ayudar a ser utilizadas en otros frameworks también. Muchas de las cosas son compartidas, como cómo manejas CSS o cómo quieres realmente construir. En términos de construcción, Veed es un poco más opinado porque queremos tener la herramienta que maneje el servidor de desarrollo y el proceso de construcción en la misma herramienta, porque la gente está acostumbrada a que Vue CLI haga eso. Así que queremos llevar esas características. Y eventualmente, esencialmente extraemos todas las cosas que aprendimos en Vue CLI, combinadas con estas nuevas ideas, y llegamos a algo que... Creo que una de las cosas interesantes es que Veed está diseñado para ser un poco más listo para usar, para que los usuarios existentes de Vue CLI o Create React app puedan moverse un poco más sin problemas, porque se adapta a lo que están acostumbrados, como la forma en que ciertas cosas se supone que deben funcionar.

la última década. Era como, Webpack hará todo. Y así, ha habido un movimiento real hacia otras herramientas para resolver el empaquetado utilizando más lenguajes compilados y WASM. No creo que ninguna de estas herramientas sería la mitad de impresionantes como lo son si no pudiéramos descansar sobre los hombros de ES Build y SWC. Así que, un gran saludo a ellos. Ellos están impulsando mucho de esto a nivel más bajo. Y luego, sí, simplemente dejando que el navegador alcance durante la última década.

Supongo que se está convirtiendo en una especie de convención compartida entre las herramientas, así que hacemos un poco más en ese aspecto. Así que sí, creo que a un alto nivel, realmente queremos que Vue sea algo con lo que puedas enviar sitios de producción hoy, porque tenemos usuarios existentes que están utilizando una herramienta que hemos construido anteriormente. Ya están enviando cosas a producción, así que queremos que nuestra nueva cosa les permita realmente mover sitios de producción en lugar de decir que esto es solo exploratorio, no lo uses para producción. Así que realmente hemos pasado mucho tiempo tratando de asegurarnos de que haya paridad de características entre estas cosas. Supongo que, sí, de alguna manera tenemos que hacer muchos compromisos más pragmáticos, donde digamos que realmente esperamos poder empaquetar con ESBuild para producción, pero al mismo tiempo, hay ciertas cosas que todavía son un poco difíciles para nosotros hacer con ESBuild directamente, así que finalmente optamos por usar Rollup para las construcciones de producción. Así que un montón de compromisos que hicimos están realmente tratando de asegurarnos de que los usuarios existentes aún puedan obtener lo que están acostumbrados, pero aún así obtener algunos de los beneficios de los nuevos modelos de desarrollo durante el desarrollo.

Eso es increíble, realmente gran trabajo. Así que voy a, de hecho, porque Swig ha mencionado Roam antes, y no tenemos a nadie de Roam en el panel, aunque fueron invitados, así que deseamos que estuvieran aquí, te dejaré intentar hacer una especie de visión general sobre Roam y cómo se diferencia de las herramientas discutidas ya, y luego pasaremos a más cosas. Así que, de nuevo, no me siento calificado para hablar de ello, pero he hablado con Jamie y Sebastian, y así que Roam es un, no está al mismo nivel que Veetz o Skypack o Snowpack, está más en el nivel de intentar reemplazar un montón de herramientas, así que si miras su, de hecho publicaron, cuando anunciaron su información de recaudación de fondos como empresa, publicaron su presentación para inversores también, así que de hecho compartiría eso en el Discord, pero esencialmente están tratando de reemplazar Babel, Webpack, Sass, Storybook, ESLint, Prettier, Styleint, Gulp, Jest, NPM, PostCSS, YesDoc, TypeScript, Cursor, y así sucesivamente. Suena ambicioso. Sí, así que como la herramienta todo en uno, y de hecho lo veo como la respuesta de Node a Denno en el sentido de que, Node tiene un conjunto de características muy definido en este momento, pero no hace muchas de las otras cosas que queremos como formateo, como linting, donde típicamente tenemos que configurar todo esto, así que tomarías una aplicación Node existente y le añadirías Roam encima. Quiero decir, también hace empaquetado, así que ahí es donde compite, pero su alcance es mucho más grande, y también tiene cero dependencias, así que quieren escribir todo esto desde cero. Creo que la otra opinión fuerte que tienen es que quieren escribirlo todo en TypeScript, así que no hay piezas de herramientas poliglotas aquí también, así que es un marco muy fuertemente opinado. En este momento, solo hacen linting, hasta donde yo sé. Así que la visión frente a la realidad hoy es aún muy marcada, pero estas dos personas tienen algunos de los antecedentes más sólidos en JavaScript, así que definitivamente vale la pena prestar atención a ello.

Eso es realmente interesante. Así que, me gusta la comparación con herramientas más antiguas, pero dado que lo mencionaste brevemente, te dejaré desglosar eso, irónicamente, y cuéntanos un poco sobre las diferencias, ¿verdad? Así que, lo que estabas usando hasta ahora, y lo que ha mejorado significativamente ahora que puedes adoptar herramientas de construcción de nueva generación. Sí, claro. Así que, podría ser el más tipo de viejo gritando a las nubes en esto porque comenzamos a mirar esto tan temprano cuando era solo un espacio dominado por web-pack, y ahora hay un montón más de opciones.

Pero en ese momento, esto fue de vuelta en 2018, 2019, simplemente no podías importar React en el navegador. Tenías que básicamente usar un empaquetador o usar la construcción UMD, lo que significa que eres como window.reactdm y window.reactdomin, y haciendo este enfoque más manual, realmente no tenía la misma conveniencia de que entras a un web-pack y realmente puedes usar ESM, y puedes usar una sintaxis que se siente realmente moderna y fresca. Pero detrás de escena, web-pack estaba como tomando eso y haciendo mucho trabajo para empaquetarlo por ti para que funcionara en un navegador que tal vez no tenía esa primitiva, esa sintaxis de importación-exportación. Y así, muchos de mis primeros días fueron como, no, no necesitas hacer todo esto, pero fue solo porque estas primitivas estaban ahora finalmente en el navegador. Y así, sí, dominaron la última década porque era realmente la única forma de obtener una experiencia de desarrollador moderna que realmente funcionara en todos los navegadores. Pero lo que hemos visto ahora que tenemos estas primitivas es que algunas de las comprensiones básicas de lo que es una herramienta de desarrollo están siendo revisadas. Así que la idea de tener que volver a empaquetar tu sitio cada vez que guardas, o ejecutar un montón de procesamiento en grandes partes de tu sitio durante el desarrollo, esas están siendo revisadas, y muchas de ellas están desapareciendo a favor de lo que V8 y Snowpack hacen, que es tratar tus archivos individuales como construcciones individuales y no necesariamente tener que, oh, Evan, no quiero hablar por ti, creo que Snowpack podría ir un poco más dramáticamente en esta dirección, pero pensando incluso en el empaquetador como una herramienta opcional en tu cadena de herramientas. Y si no necesitas empaquetar, no te importa eso, no tienes que, puedes traerlo cuando quieras cuando estés listo para abordar el rendimiento o para ir a producción. Así que todas estas cosas fundamentales sobre cómo construimos sitios web están siendo revisadas por primera vez en un tiempo. Es un momento realmente emocionante. Sí, suena emocionante. Evan, te permitiré intervenir aquí y contarnos un poco sobre cómo V8 es diferente, en qué se está enfocando V8, qué hay en la hoja de ruta en términos de llevarlo hacia adelante como una herramienta de construcción de nueva generación. Claro. Así que para mí, V8 comenzó realmente con la necesidad que tengo para mí mismo porque construimos Vue CLI, que está basado en webpack. Y cuando construí Vue CLI, teníamos este tipo de comando menos conocido llamado VueServe, que es un comando global que simplemente te permite iniciar un servidor de desarrollo para un archivo Vue sin ninguna configuración en absoluto. Solo necesitas un archivo, y puedes usar ese comando para iniciar un servidor de desarrollo. Y me gusta eso, pero con el tiempo, sigue siendo como, para hacerlo, tienes que instalar Vue CLI globalmente, y todo el proceso sigue siendo más lento de lo que hubiera esperado.

Siempre quise tener esta cosa donde literalmente puedo iniciar un servidor de desarrollo en milisegundos y tener algo en la pantalla de inmediato.

Es interesante que ahí es donde lo envolviste, porque esa es la primera pregunta que llegó de la comunidad, que en realidad trata sobre opinado versus configurable como una tendencia en herramientas. ¿Puedes desglosar eso un poco? La pregunta era realmente que Webpack y Babel son ambos súper flexibles, pero ESbuild no lo es intencionalmente, Roam todo en uno, y tú hablaste sobre Roam siendo un poco opinado, así que un poco sobre herramientas de construcción más opinadas versus las más configurables y flexibles.

Te dejaré continuar con eso, y luego pasaremos a Fred. Creo que es una dicotomía falsa esencialmente. Tuvimos un breve período donde zero config.js era genial, y luego dijimos, oh, en realidad, no, todos necesitan configurar cosas, así que intentaremos tener buenos valores predeterminados. Creo que eso es lo que todos quieren. Yup, gracias por eso. Genial. Fred, ¿cuáles son tus pensamientos? Sí, estaba en silencio allí. Siento que estoy haciendo trampa. De hecho, hice mi pregunta tratando de solo ver si esta idea funciona.

No, mi nombre es diferente en Discord, así que prometo que no fue intencional. No, creo que hay algo interesante sucediendo aquí. No sé si es tan concreto como una verdadera tendencia, pero hay esta idea que ves en Webpack y Babel, esta como completa personalización de un plugin puede hacer cualquier cosa. Puedes personalizar tu construcción por completo. Es esta plataforma realmente poderosa. No estoy viendo eso tanto en las herramientas más nuevas, como ES Build está siendo realmente intencional en cuanto a donde es JavaScript, puedes tal vez compilar algo como Svelte o U2 JavaScript, pero no te estamos dando tanto control como lo hizo Webpack.

tenía esa prueba de concepto, pero en ese momento, realmente era solo una prueba de concepto, porque en ese momento, muy pocas personas realmente usaban importaciones ES nativas, y pensé, tal vez esto es solo demasiado temprano, pero un año o dos después, me di cuenta, oh, todos los navegadores principales hoy en día realmente vienen con importaciones ES nativas. Tal vez es hora de revisar esa idea, pero al mismo tiempo, estaba tratando de averiguar cómo funcionaría el reemplazo de módulos en caliente, porque eso es algo que se está volviendo esencial para flujos de trabajo a gran escala. Y revisité el proyecto, finalmente descubrí cómo hacer el reemplazo de módulos en caliente con módulos ES nativos, y esa fue una especie de forma inicial, cómo Veed tomó forma. Y me di cuenta de que esto podría ser más que solo una herramienta de prototipado, así que a un nivel más alto, Veed se basa en eso y estamos tratando de realmente, creo que el objetivo inicial era proporcionar algo más cercano en experiencia de desarrollo a Vue CLI, porque queremos tener un equivalente más ligero, ágil y moderno a Vue CLI para nuestros usuarios. Pero a lo largo del camino, a medida que construimos más y más características, como mover las características equivalentes a Veeds, nos damos cuenta de que muchas de ellas no son específicas de Vue, en realidad pueden ayudar a ser utilizadas en otros frameworks también. Muchas de las cosas son compartidas, como cómo manejas CSS o cómo quieres realmente construir. En términos de construcción, Veed es un poco más opinado porque queremos tener la herramienta que maneje el servidor de desarrollo y el proceso de construcción en la misma herramienta, porque la gente está acostumbrada a que Vue CLI haga eso.

Así que queremos llevar esas características. Y eventualmente, esencialmente extraemos todas las cosas que aprendimos en Vue CLI, combinadas con estas nuevas ideas, y llegamos a algo que... Creo que una de las cosas interesantes es que Veed está diseñado para ser un poco más listo para usar, para que los usuarios existentes de Vue CLI o Create React app puedan moverse un poco más sin problemas, porque se adapta a lo que están acostumbrados, como la forma en que ciertas cosas se supone que deben funcionar. Supongo que se está convirtiendo en una especie de convención compartida entre las herramientas, así que hacemos un poco más en ese aspecto. Así que sí, creo que a un nivel alto, realmente queremos que Vue sea algo con lo que puedas enviar sitios de producción hoy, porque tenemos usuarios existentes que están utilizando una herramienta que hemos construido anteriormente. Ya están enviando cosas a producción, así que queremos que nuestra nueva cosa les permita realmente mover sitios de producción en lugar de decir que esto es solo exploratorio, no lo uses para producción. Así que realmente hemos pasado mucho tiempo tratando de asegurarnos de que haya paridad de características entre estas cosas. Supongo, sí, así que de alguna manera tenemos que hacer muchos compromisos más pragmáticos, donde decimos que realmente esperamos poder empaquetar con ESBuild para producción, pero al mismo tiempo, hay ciertas cosas que todavía son un poco difíciles para nosotros hacer con ESBuild directamente, así que eventualmente optamos por usar Rollup para construcciones de producción. Así que un montón de compromisos que hicimos están realmente tratando de asegurarnos de que los usuarios existentes aún puedan obtener lo que están acostumbrados, pero aún así obtener algunos de los beneficios de los nuevos modelos de desarrollo durante el desarrollo. Eso es increíble, realmente gran trabajo. Así que voy a, de hecho, porque Swig mencionó Roam antes, y no tenemos a nadie de Roam en el panel, aunque fueron invitados, así que deseamos que estuvieran aquí, te dejaré intentar hacer un resumen sobre Roam y cómo se diferencia de las herramientas discutidas ya, y luego pasaremos a más cosas.

Creo que a lo largo de los años, es una de las razones por las que estas plataformas son tan populares, pero al mismo tiempo, todavía hay personas que tienen problemas para actualizar de Webpack 4 a 5 mucho más tiempo después de su lanzamiento. Y Babel, es un gran ecosistema, pero luego tiene estos problemas que tal vez Roam está tratando de resolver, y es una especie de todo en uno. Así que creo que hay algo que tal vez es un empuje y tirón constante en las herramientas de la web, pero todo ese poder, la personalización, y como el control total que te da termina siendo en realidad un obstáculo cuando se lleva al extremo. Y sé que vemos esto con Snowpack a menudo cuando la gente pregunta qué se necesita para migrar de una aplicación Webpack más antigua a Snowpack. La pregunta es realmente como que depende de cuán profundo en el agujero de Webpack has ido. Si has personalizado cada posible importación para hacer estas cosas que no son realmente JavaScripty, no es realmente una limitación de Snowpack, es una limitación de usar las primitivas del navegador en las que te has metido, el agujero del que necesitas salir. Así que sabes, es este interesante empuje y tirón entre los dos.

Interesante. Queremos incluir mucho más en este panel, así que te voy a pedir, Evan, que mantengas tu respuesta breve para que podamos pasar a algunas de las preguntas de la comunidad que están llegando. La gente quiere hacerle algunas preguntas a este equipo Powerhouse. Así que rápidamente sobre esto y luego cerraremos este tema. Claro, claro. Sí, así que mi experiencia personal con V es un poco similar, como que creo que juega con cómo Webpack comenzó inicialmente no solo apuntando a aplicaciones web, ¿verdad?, en realidad puedes usarlo para empaquetar un paquete de node.js y enviarlo para node.js. Así que fue diseñado para cubrir una gama mucho más amplia de casos de uso y todavía lo hace, ¿verdad?, lo que solo aumenta la superficie del problema y su complejidad inherente. Tiene que ser tan flexible para poder manejar todos estos diferentes casos, pero por otro lado, digamos Vtorch Snowpack, estamos realmente enfocados en la web donde estamos construidos con la suposición de que estás tratando de construir una aplicación web, ¿verdad?. Cuando defines el espacio del problema a uno más estrecho, puedes hacer más suposiciones, puedes sortear más convenciones para hacerlo más eficiente porque sabemos que estás lidiando con un tipo específico de problemas.

eso en el Discord, pero esencialmente están tratando de reemplazar Babel, Webpack, Sass, Storybook, ESLint, Prettier, Styleint, Gulp, Jest, NPM, PostCSS, YesDoc, TypeScript, Cursor, y así sucesivamente. Suena ambicioso. Sí, así que es como el marco de herramientas todo en uno, y de hecho lo veo como la respuesta de Node a Deno en el sentido de que Node tiene un conjunto de características muy definido en este momento, pero no hace muchas de las otras cosas que queremos como formateo, como linting, donde típicamente tenemos que configurar todo esto, así que tomarías una aplicación Node existente y le añadirías Roam encima. Quiero decir, también hace bundling, así que ahí es donde compite, pero su alcance es mucho más grande, y también tiene cero dependencias, así que quieren escribir todo esto desde cero. Creo que la otra opinión fuerte que tienen es que quieren escribirlo todo en TypeScript, así que no hay piezas de herramientas poliglotas aquí también, así que es un marco muy opinado. En este momento, solo hacen linting, hasta donde yo sé. Así que la visión frente a la realidad hoy en día es aún muy marcada, pero estas dos personas tienen algunos de los historiales más sólidos en JavaScript, así que definitivamente vale la pena prestar atención.

Sí, eso tiene mucho sentido. La siguiente pregunta que voy a dirigir a uno o dos de ustedes a la vez porque quiero obtener información. Así que la siguiente pregunta que surgió de la comunidad. ¿Creen que en algún momento superaremos las limitaciones del navegador, por ejemplo, en términos de una gran cantidad de rendimiento de carga de módulos? Preguntaré la segunda parte de la pregunta en un momento. Así que, respondamos rápidamente a esa. Spix, ¿qué piensas? En algún momento es un período muy largo, largo. Pero el equipo de VA ha dicho oficialmente que creo que el límite es algo así como 100 o como, simplemente, es, es solo un límite físico en cuanto a cuántos quieres cargar en paralelo. Así que no lo creo. Pero tal vez los otros chicos puedan opinar. Adelante, Evan. Sí, como mi opinión personal, no estoy muy familiarizado con cómo VA planea resolverlo, pero creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con el snowpack de puerta, no estamos No, No. Pero no somos empaquetadores haciendo Dev, ¿verdad? Pero aún estamos cargando todos estos módulos a través de solicitudes HTTP, todavía hay un overhead. Y cuando el número de solicitudes paralelas es lo suficientemente grande. Como, incluso con cero latencia, todavía estás viendo mucho overhead. Así que creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con el snowpack de puerta, no estamos No, No. Pero aún estamos cargando todos estos módulos a través de solicitudes HTTP, todavía hay un overhead. Y cuando el número de solicitudes paralelas es lo suficientemente grande. Como, incluso con cero latencia, todavía estás viendo mucho overhead. Así que creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con la puerta Así que creo que es un problema intrínsecamente difícil cuando intentas cargar tantos módulos a través de la red.

Así que no estoy seguro si esto es algo que se puede resolver a corto plazo, a largo plazo, puede que requiera alguna innovación fundamental a nivel de protocolo para ver este cambio. Qué interesante transición porque esa es la segunda parte de la pregunta, no estoy seguro si ya la respondiste o no, pero básicamente la otra mitad de la pregunta era, tenemos HDTV, HTTP para tener un trabalenguas y NDSM, pero al mismo tiempo, todavía tendemos a estar mejor con un paquete de empaquetado. A veces con división de código. ¿Cuál es tu opinión sobre lo que falta en los estándares ECMAScript del navegador para permitir trabajar con módulos, fuera de la caja, sin ningún inconveniente de rendimiento? Podemos ver ahora mismo, así que siento que tocaste un poco ese hilo sólido, expande un poco sobre eso. Sí, quiero decir, es algo que todo el tiempo está mejorando un poco, como ahora tenemos HTTP tres, y eso es aún mejor en este multiplexado de recursos. Así que, en realidad, separando múltiples archivos que se cargan en casi flujos separados dentro de esa conexión para que un paquete caído no afecte toda la conexión. Hay muchas cosas sucediendo en la capa de red que están apuntando, no realmente explícitamente, pero de alguna manera, de forma no intencionada, como un buen impacto aquí. Mejor rendimiento de carga no empaquetada. Ahora eso todavía no es, ya sabes, al final del día, 1000 archivos versus un archivo, va a ser más lento.

Es interesante que ahí es donde lo envolviste, porque esa es la primera pregunta que llegó de la comunidad, en realidad sobre lo opinado versus configurable como una tendencia de herramientas. ¿Puedes desglosar eso un poco? La pregunta era realmente Webpack y Babel son ambos súper flexibles, pero ES Build no lo es intencionalmente, Roam todo en uno, y tú hablaste sobre Roam siendo un poco opinado, así que un poco sobre herramientas de construcción más opinadas versus las más configurables y flexibles. Te dejaré continuar con eso, y luego pasaremos a Fred. Creo que es una falsa dicotomía esencialmente. Tuvimos un breve período donde zero config.js era genial, y luego dijimos, oh, en realidad, no, todos necesitan configurar cosas, así que intentaremos tener buenos valores predeterminados. Creo que eso es lo que todos quieren. Yup, gracias por eso. Genial. Fred, ¿cuáles son tus pensamientos? Sí, estaba en silencio ahí. Siento que estoy haciendo trampa. De hecho, hice mi pregunta tratando de solo ver si esta idea funciona. No, mi nombre es diferente en Discord, así que prometo que no fue intencional. No, creo que hay algo interesante sucediendo aquí. No sé si es tan concreto como una verdadera tendencia, pero hay esta idea que ves en Webpack y Babel, esta como personalización completa de un plugin puede hacer cualquier cosa. Puedes personalizar tu construcción por completo. Es esta plataforma realmente poderosa. No estoy viendo eso tanto en las herramientas más nuevas, como ES Build está siendo realmente intencional en cómo es JavaScript, puedes tal vez compilar algo como Svelte o U2 JavaScript, pero no te estamos dando tanto control como lo hizo Webpack. Creo que a lo largo de los años, es una de las razones por las que estas plataformas son tan populares, pero al mismo tiempo todavía tienes personas teniendo problemas para actualizar de Webpack 4 a 5 tanto tiempo después de su lanzamiento. Y Babel, es un gran ecosistema, pero luego tiene estos problemas que tal vez Roam está tratando de resolver, y es como un stack todo en uno. Así que creo que hay algo que tal vez es solo un constante tira y afloja en las herramientas de la web, pero todo ese poder, la personalización, y como el control total que te da termina siendo en realidad un obstáculo cuando se lleva al extremo. Y sé que vemos esto con Snowpack a menudo cuando las personas preguntan qué se necesita para migrar de una aplicación más antigua de Webpack a Snowpack. La pregunta es realmente como que depende de cuán profundo en el agujero de Webpack has ido. Si has personalizado cada posible importación para hacer estas cosas que no son realmente JavaScripty, no es realmente una limitación de Snowpack, es una limitación de usar los primitivos del navegador en los que te has metido en el agujero del que necesitas salir. Así que sabes, es este interesante tira y afloja entre los dos. Interesante. Queremos encajar mucho más en este panel, así que te voy a pedir, Evan, que mantengas tu respuesta breve para que podamos pasar a algunas de las preguntas de la comunidad que están llegando. La gente quiere hacerle algunas preguntas a este equipo Powerhouse. Así que rápidamente sobre este y luego cerraremos este. Claro, claro.

rápidamente sobre este y luego cerraremos este. Claro, claro. Sí, así que mi experiencia personal con V es algo similar, como creo que juega un poco con cómo Webpack comenzó inicialmente no solo apuntando a aplicaciones web, ¿verdad? Puedes usarlo para agrupar un paquete de node.js y enviarlo para node.js. Así que fue diseñado para cubrir una gama mucho más amplia de casos de uso y todavía lo hace, ¿verdad? Lo que solo aumenta la superficie del problema y su complejidad inherente. Tiene que ser lo suficientemente flexible para poder manejar todos estos diferentes casos, pero por otro lado, digamos Vtorch Snowpack, estamos realmente enfocados en la web donde estamos construidos con la suposición de que estás tratando de construir una aplicación web, ¿verdad? Cuando defines el espacio del problema a uno más estrecho, puedes hacer más suposiciones, puedes sortear más convenciones para hacerlo más ágil porque sabemos que estás lidiando con un tipo específico de problemas. Pero aún así, incluso dentro de eso, siempre hay una especie de tienes que averiguar dónde caen los valores predeterminados sensatos realmente. Solo puedes averiguarlo con el tiempo, ¿verdad? Cuando las personas realmente construyen cosas con tus herramientas y te das cuenta de lo que tiene sentido, lo que no.

Sí, eso tiene mucho sentido. Las siguientes preguntas que voy a dirigir a uno o dos de ustedes a la vez porque quiero incluir cosas. Así que la siguiente pregunta que surgió de la comunidad. ¿Creen que en algún momento superaremos las limitaciones del navegador, por ejemplo, en términos de rendimiento de carga de módulos masivos? Preguntaré la segunda parte de la pregunta en un momento. Así que, respondamos rápidamente a esa. Spix, ¿qué piensas? En algún momento es un periodo muy largo, largo. Pero el equipo de VA ha dicho oficialmente que creo que el límite es algo así como 100 o como, simplemente, es, es solo un límite físico en cuanto a cuántos quieres cargar en paralelo. Así que no lo creo. Pero tal vez los otros chicos puedan opinar. Adelante, Evan. Sí, como mi opinión personal, no estoy muy familiarizado con cómo VA planea resolverlo, pero creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con el snowpack de puerta, no somos No, No. Pero no somos agrupadores haciendo Dev, ¿verdad?, pero aún estamos cargando todos estos módulos a través de solicitudes HTTP, todavía hay un overhead. Y cuando el número de solicitudes paralelas es lo suficientemente grande. Como incluso con cero latencia, todavía estás viendo mucho overhead. Así que creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con el snowpack de puerta, no somos No, No. Pero aún estamos cargando todos estos módulos a través de solicitudes HTTP, todavía hay un overhead. Y cuando el número de solicitudes paralelas es lo suficientemente grande. Como, incluso con cero latencia, todavía estás viendo mucho overhead. Así que creo que el cuello de botella está realmente en la red, como, incluso localmente, digamos, con la puerta Así que creo que es un problema intrínsecamente difícil cuando intentas cargar tantos módulos a través de la red. Así que no estoy seguro si esto es algo que se puede resolver a corto plazo, a largo plazo, puede que requiera alguna innovación fundamental a nivel de protocolo para ver este cambio. Qué interesante transición porque esa es la segunda parte de la pregunta, no estoy seguro si ya la respondiste o no, pero básicamente la otra mitad de la pregunta era, tenemos HDTV, HTTP para tener un trabalenguas y NDSM, pero al mismo tiempo, todavía tendemos a estar mejor con la agrupación de un paquete. A veces con división de código. ¿Cuál es tu opinión sobre lo que falta en los estándares ECMAScript del navegador para permitir trabajar módulos, fuera de la caja sin ningún inconveniente de rendimiento? Podemos ver ahora mismo, así que siento que has tocado un poco ese hilo sólido, expande un poco sobre eso. Sí, quiero decir, es algo que todo está constantemente mejorando un poco, como ahora tenemos HTTP tres, y eso es aún mejor en este multiplexado de recursos. Así que, en realidad, separando múltiples archivos que se cargan en casi flujos separados dentro de esa conexión para que un paquete caído no hunda toda la conexión. Hay muchas cosas sucediendo en la capa de red que están apuntando, no realmente explícitamente, pero de alguna manera involuntariamente como un buen impacto aquí. Mejor rendimiento de carga no agrupada. Ahora eso todavía no es, ya sabes, al final del día, 1000 archivos versus un archivo, va a ser más lento. En ese tiempo de carga inicial, especialmente, así que comienza a convertirse más en un juego de compromisos, diría yo, donde si estás construyendo algo que es más una aplicación, como tu bandeja de entrada en Gmail y es algo a lo que vas a abrir, vuelves, está constantemente en una pestaña y abierta.

Estás tratando de optimizar para alguien que es un cliente recurrente, un visitante del sitio, y luego la historia de caching de un sitio menos agrupado se convierte en una parte interesante de esto, donde si puedes. Quiero decir, mirando el extremo de cada archivo servido individualmente al usuario. Lo que eso significa es que cuando uno cambia, tienes la oportunidad de enviar solo ese cambio al navegador. Así que, en lugar de reenviar un paquete completo y cada vez que, ya sabes, cualquier ingeniero de Google empuja el cambio, terminas reagrupando Todo el sitio y reenviando eso a cada usuario porque explota la caché de un solo paquete. Obtienes algo que es mucho más flexible, hay un montón de complejidad que se puede ignorar en sus estrategias de caching de huellas digitales, pero se convierte en menos de un Cada caso de uso, tienes que hacer esta cosa y en su lugar, un poco más de un compromiso basado en tu caso de uso basado en el rendimiento y Y de nuevo, la pila de redes que continúa mejorando en los navegadores realmente está en este tipo de Modelo Evergreen donde están mejorando a un ritmo mucho más rápido de lo que lo hicieron hace 10-20 años. Eso es super interesante.

Hay esta idea de rendimiento realmente interesante donde ya no estás optimizando para esa primera carga de página. Estás tratando de optimizar para alguien que es un cliente recurrente, un visitante del sitio, y luego la historia de caché de un sitio menos empaquetado se convierte en una parte interesante de esto, donde si puedes. Quiero decir, mirando el extremo de cada archivo servido individualmente al usuario. Lo que eso significa es que cuando uno cambia, tienes la oportunidad de enviar solo ese cambio al navegador. Así que, en lugar de reenviar un paquete completo y cada vez que sabes que cualquier ingeniero en Google empuja el cambio, terminas reempaquetando Todo el sitio y reenviando eso a cada usuario porque explota la caché de un solo paquete. Obtienes algo que es mucho más flexible, hay un montón de complejidad que se puede ignorar en sus estrategias de caché de huellas digitales, pero se convierte en menos de un Cada caso de uso, tienes que hacer esta cosa y en su lugar, un poco más de una compensación basada en tu caso de uso basado en rendimiento y Y de nuevo, la pila de redes continúa mejorando en los navegadores realmente estando en este tipo de modelo Evergreen donde están mejorando a un ritmo mucho más rápido de lo que lo hicieron hace 10-20 años.

Eso es súper interesante. De hecho, quiero llegar a los casos de uso, pero veo que hay más preguntas de la comunidad. Así que voy a Hacer las preguntas de la comunidad. Y creo que vamos a concluir con la pregunta sobre como Sabes, los casos de uso, los casos de uso ideales para los cuales herramienta. Así que la siguiente pregunta de la comunidad es, VIT es el nuevo chico en el bloque para mí. ¿Cómo se compara con Snowpack? Oh, oh, está bien, dejaré que Swift tome eso. Espera, espera, espera. ¿VIT o Qué, ¿por qué yo, por qué no Fred? Porque es VIT versus Snowpack. Siento que no tengo ninguna Me encantaría escuchar la respuesta de Evans sobre esto. Bueno, ambos son geniales. Adelante, Evan. Adelante Evan, está bien. Así que creo que, ya sabes, en términos de solo rendimiento de desarrollo, los dos proyectos son muy similares. Porque estamos en ambos módulos nativos VS con reemplazo de módulo caliente. Creo que la historia difiere un poco en términos de construcción de producción, donde, como mencioné antes, Vite fue diseñado para ayudar a los usuarios existentes de UCI o crear aplicaciones de React a moverse con un flujo de trabajo similar. Lo que significa que están acostumbrados a desarrollar y luego solo empaquetar y construir todo con la misma herramienta. Así que Vite intencionalmente elige este conjunto de construcción preconfigurado opinado para ti. Para que sea solo una herramienta que maneje tanto el desarrollo como la construcción y porque de alguna manera te obliga a ir con la solución de construcción que hemos elegido para ti, podemos hacer un poco más de suposiciones y simplemente optimizar un poco más. Porque ciertas cosas que puedes necesitar coordinar entre tu servidor de desarrollo y la tubería de construcción porque controlamos ambos. Así que podemos hacer un poco más de acoplamiento allí. Ciertas cosas, ciertas características que haces durante el desarrollo, podemos de alguna manera hacer un caso especial en la construcción para hacerlo más eficiente al final. Así que es una especie de compensación. Snowpack, por otro lado, separa un poco más los dos procesos. Puedes construir tus archivos empaquetados o puedes usar el optimizador ESBuild incorporado o puedes usar Webpack.

Técnicamente puedes usar cualquier empaquetador para empaquetar archivos fuente de VEET también, pero obviamente la mayoría de los usuarios solo usan el empaquetador basado en rollup por defecto. Así que el intercambio aquí es que con Snowpack, obtienes tener algunas opciones más, pero estas diferentes opciones tienen diferentes intercambios. Tienes que investigarlas y decidir por ti mismo. Mientras que VEET simplemente dice, solo usa esto, hacemos las optimizaciones, hemos resuelto muchas cosas por ti. Así que para las personas que están acostumbradas a tener una herramienta que maneje ambas, es una transición más natural y estamos un poco más enfocados en proporcionarte algo que al menos sea equivalente a lo que estás acostumbrado. Porque realmente es el objetivo principal para nosotros, al menos en el ecosistema de VUE, necesita llenar el vacío de VUE CLI para las personas que quieren salir de Webpack.

Así que personalmente para mí, esa es una gran diferencia. Pero aparte de eso, sabes, hay muchas áreas en las que creo que los dos proyectos son realmente similares en términos de experiencia de desarrollo, ambos son increíblemente rápidos. Y. Oh sí, otra cosa es que, somos opinados sobre la configuración de construcción, así que puedes usar fácilmente la construcción. Estamos dando esta interfaz de plugin que es compatible con Rola, que funciona tanto en desarrollo como en producción. Esto está inspirado en WMR. Sí, realmente creo que ahí es donde radica la principal diferencia. Y, pero juega en este objetivo de nivel superior donde VEET está tratando de, dentro del ecosistema de VUE, estamos tratando de proporcionar una alternativa. Eso es a Vue CLI.

Así que los objetivos pueden, sabes, desviarse un poco dependiendo de lo que estás tratando de lograr. Entendido. Está bien, eso es interesante Fred, ¿quieres agregar algo? Sí, eso es un resumen acertado, creo que realmente, olvidé. Sí, WMR definitivamente merece un reconocimiento también, probablemente la tercera herramienta en este tipo de grupo que está explorando un espacio similar, todos están basados en los mismos principios fundamentales de qué tecnología, podemos aprovechar para obtener este rendimiento. Y luego, como mencionó Kevin, creo que ahí es donde encajamos en las características existentes y cómo entrega lo que entrega. Creo que es donde están las mayores diferencias, así que manejar tus dependencias. Evan creo que usa ES build en este punto y rollup en el paquete final está construido en. Casi completamente invierte eso, vimos muchos problemas usando ES build en algunos de los paquetes del ecosistema de React. Así que terminamos usando o continuamos usando rollup en esa etapa. Y solo esperando que ES build avance un poco más hasta que desarrollemos eso. De nuevo, eso es de hace un par de meses, así que tal vez ya se haya resuelto.

Y luego, por el otro lado, sí, estamos tratando de experimentar con ES Build como un empaquetador de producción. Pero sabes que obtengo Rollup como una herramienta mucho más madura allí, así que definitivamente obtienes mucho más al conectar Webpack o Rollup en nuestra optimización final de producción, así que realmente son espacios similares en los que estamos jugando y es realmente genial ver cómo todos conectamos las herramientas de manera diferente. Estoy seguro de que esto lo resolveremos a medida que avancemos y crezcamos y esto se revelará.

Sí. Ni siquiera me di cuenta hasta que mencionaste que en realidad somos completamente opuestos. Sí. Sí, es gracioso. Genial. Y así, añadiendo a la mezcla de la comunidad, alguien preguntó que le encantaría escuchar tus pensamientos sobre el uso de herramientas como Bazel para construir aplicaciones web. Y habías hablado mucho sobre el rendimiento increíblemente rápido y que ese tipo de ser el enfoque principal para ambas herramientas. Así que la pregunta era, ¿son estas herramientas de alto rendimiento el objetivo final? Permíteme, Fred, continuar. Sí, ahora siento que no soy la persona adecuada para responder a esta pregunta, no tengo experiencia con ninguno de esos sistemas de construcción. Sabes que definitivamente hay algo sucediendo aquí con cómo se conectan, pero sí, no sé lo suficiente sobre ellos para hablar. Está bien, genial. Entonces, Swix, ¿quieres tomarlo? No. Yo tampoco he usado esos. Está bien, entonces, Evan. Adelante. Honestamente, no. Solo sé brevemente sobre Bazel porque cuando estaba en Google, sé que esta es esencialmente la versión de código abierto de Blaze, que es el sistema de construcción interno de Google. Pero cuando se trata de, digamos, aplicaciones web, la mayoría del tiempo todavía estás gastando en llamar a tus herramientas del ecosistema, como si estuvieras transpiling React JSX, ¿verdad? Eso no es parte de Bazel. O estás tratando de compilar un archivo de vista o un archivo de hechizo. Esos no son manejados por Bazel. Así que, solo tener una herramienta de construcción que sea rápida no necesariamente, simplemente no constituye el principal cuello de botella en términos de cuando hablas de construir una aplicación web completa, ¿verdad? El empaquetado y la minificación de JavaScript, todos estos son específicos del front-end. Bazel es una herramienta de construcción genérica que no se preocupa por estas preocupaciones específicas. Así que, realmente no sé si realmente se aplica en términos de rendimiento general. Diría que solo obtienes este tipo de ganancia de rendimiento tipo salto cuántico de ESBuild cuando realmente pones todas estas preocupaciones específicas del front-end y las manejas con un lenguaje nativo, ¿verdad? La razón por la que ESBuild es mucho más rápido en un benchmark de empaquetado completo más minificación es porque hace todo esto dentro de Go sin realmente llamar a JavaScript. En el momento en que tienes que usar un plugin de ESBuild para llamar a JavaScript, en realidad ralentiza todo un poco también. Voy a contribuir un poco aquí, si puedo.

Voy a aportar un poco aquí, si puedo. Sí, está bien. Así que, el año pasado, en realidad hice un livestream con Minko Gechev del equipo central de Angular, y él mostró un poco de cómo utilizan Bazel. Y en realidad están más enfocados en construcciones remotas. Ustedes dos están más en la experiencia de desarrollo local, pero para ellos, quieren escalarlo para la construcción y el almacenamiento en caché remotos.

Así que, dejaré el enlace a ese livestream allí con la marca de tiempo. Está bien, estoy de vuelta. Me disculpo por eso. Tuve algún tipo de dificultad técnica. Mis disculpas. Hay otra pregunta de la comunidad y no quería tocar casos de uso que no conozco cuánto tiempo tenemos. Así que voy a hacer la pregunta de la comunidad porque para eso están aquí las personas. Así que la siguiente pregunta fue, ¿crees que en algún momento Angular cambiará Webpack por alguna otra herramienta de construcción? ¿Webpack se pondrá al día con el mercado? ¿O se convertirá en el jQuery de las herramientas de construcción? Sí, vamos a las respuestas sobre esto. Angular tiene su propio ecosistema, pero no parece estar creciendo en uso entre los nuevos desarrolladores. Creo que si tenemos una herramienta que está profundamente integrada con Webpack.

A menos que la diseñes desde el primer día para ser agnóstica en cuanto a agrupación, no creo que sea un intercambio fácil decir que vamos a cambiar a un agrupador diferente porque típicamente cuando usas Webpack, vas a tener un acoplamiento muy, muy estrecho con cómo funcionan sus plugins, cómo funcionan sus pipelines, vas a depender de muchas cosas específicas que Webpack proporciona. Y eso es, creo que no creo que Webpack se convierta en el nuevo jQuery, sigue siendo una herramienta poderosa y probablemente todavía está funcionando lo suficiente para muchos casos de uso. Y tiene algunas características bastante importantes que otros agrupadores no tienen, como por ejemplo, la federación de módulos es algo que es bastante interesante, que no creo que esté presentando otros agrupadores en este momento. Así que todavía hay muchas cosas interesantes que pueden potencialmente suceder en Webpack.

Así que creo que es realmente demasiado pronto para decir que se va a convertir en las herramientas de construcción de jQuery, definitivamente, quiero decir, sigue siendo enorme, ¿verdad?, todavía va a estar aquí para quedarse por lo que puedo decir. Sí. Está bien, Fred, te dejaré responder rápidamente a una pregunta y luego realmente necesitamos cerrar. Es solo un panel realmente excelente, gracias a todos. No, no tengo nada que agregar, eso fue muy bien dicho. Muy bien, así que wow, qué panel realmente impresionante. Fue un placer tenerlos a todos aquí. Hay tantas más preguntas que quiero hacer, estas mentes brillantes, pero se nos acabó el tiempo. Así que muchas gracias Evan, Swix, Fred por estar con nosotros en el panel de NextGenBuildTools. Ellos están disponibles en Discord si quieren charlar con ellos y hacerles más preguntas. Si tienen más cosas que querían que se respondieran y no tuvimos suficiente tiempo. Muchas gracias por estar con nosotros. Qué placer.

De hecho, quiero llegar a los casos de uso, pero veo que hay más preguntas de la comunidad. Así que voy a Hacer las preguntas de la comunidad. Y creo que vamos a concluir con la pregunta sobre como un tipo de Ya sabes, los casos de uso, los casos de uso ideales para los cuales para qué herramienta. Así que la siguiente pregunta de la comunidad es, VIT es el nuevo chico en la cuadra para mí. ¿Cómo se compara con Snowpack? Oh, oh, está bien, dejaré que Swift responda eso. Espera, espera, espera. ¿VIT o ¿Por qué yo, por qué no Fred? Porque es VIT contra Snowpack. Siento que no tengo ninguna respuesta objetiva Me encantaría escuchar la respuesta de Evans sobre esto. Bueno, ambos son geniales. Adelante, Evan. Adelante Evan, está bien. Así que creo que, ya sabes, en términos de solo rendimiento de desarrollo, los dos proyectos son muy similares. Porque estamos en ambos módulos nativos VS con reemplazo de módulo en caliente. Creo que la historia difiere un poco en términos de construcción de producción, donde, como mencioné antes, Vite fue diseñado para ayudar a los usuarios existentes de UCI o crear aplicaciones React a trasladarse con un flujo de trabajo similar. Lo que significa que están acostumbrados a desarrollar y luego simplemente agrupar y construir todo con la misma herramienta. Así que Vite intencionalmente elige este conjunto de construcción preconfigurado y opinado para ti. Para que sea solo una herramienta que maneje tanto el desarrollo como la construcción y porque de alguna manera te obliga a ir con la solución de construcción que hemos elegido para ti, podemos hacer un poco más de suposiciones y simplemente optimizar un poco más.

De hecho, puedes construir tus archivos en empaquetados o puedes usar el optimizador ESBuild integrado o puedes usar Webpack. Técnicamente, también puedes usar cualquier empaquetador para empaquetar archivos fuente de VITE, pero obviamente la mayoría de los usuarios solo usan el empaquetador basado en rollup por defecto. Así que la compensación aquí es que con Snowpack, obtienes algunas opciones más, pero estas diferentes opciones tienen diferentes compensaciones. Tienes que investigarlas y decidir por ti mismo. Mientras que VITE simplemente dice, solo usa esto, hacemos las optimizaciones, hemos resuelto muchas cosas por ti. Así que para las personas que están acostumbradas a tener una herramienta que maneje ambos, es una transición más natural y estamos un poco más enfocados en proporcionarte algo que al menos sea un equivalente a lo que estás acostumbrado. Porque realmente es el objetivo principal para nosotros, al menos en el ecosistema de VUE, necesita llenar el vacío de VUE CLI para las personas que quieren salir de Webpack. Así que personalmente para mí, esa es una gran diferencia. Pero aparte de eso, sabes, hay muchas áreas en las que creo que los dos proyectos son realmente similares en términos de experiencia de desarrollo, ambos son increíblemente rápidos.

Oh sí, otra cosa es que, como tenemos una opinión sobre la configuración de construcción, puedes usar fácilmente build. Estamos dando esta interfaz de plugin que es compatible con Rola, que funciona tanto en Dev como en producción. Esto está inspirado en WMR. Sí, realmente creo que ahí es donde radica la principal diferencia. Y, pero juega en este objetivo de nivel superior donde VITE está tratando de, dentro del ecosistema de VUE, estamos tratando de proporcionar una alternativa. Eso es a Vue CLI. Así que los objetivos pueden, ya sabes, desviarse un poco dependiendo de lo que estás tratando de lograr.

Entendido. Está bien, eso es interesante Fred, ¿quieres agregar algo? Sí, eso es un resumen acertado, creo que realmente, lo olvidé. Sí, WMR definitivamente merece un reconocimiento también, probablemente la tercera herramienta en este tipo de grupo que está explorando un espacio similar, todos están basados en los mismos principios fundamentales de qué tecnología podemos aprovechar para obtener este rendimiento. Y luego, como mencionó Kevin, creo que probablemente es donde encajamos en las características existentes y cómo entrega lo que entrega. Creo que es donde están las mayores diferencias, así que manejar tus dependencias. Evan creo que usa ESBuild en este punto y Rollup en el paquete final está construido en.

Casi completamente invierte eso, vimos muchos problemas usando ESBuild en algunos de los paquetes del ecosistema de React. Así que terminamos usando o continuamos usando Rollup en esa etapa. Y solo esperando que ESBuild avance un poco más hasta que desarrollemos eso. De nuevo, eso es de hace un par de meses, así que tal vez ya se haya resuelto. Y luego, por el otro lado, sí, estamos tratando de experimentar con ESBuild como un empaquetador de producción. Pero, ya sabes, Rollup es una herramienta mucho más madura allí, así que definitivamente obtienes mucho más al conectar Webpack o Rollup en nuestra optimización final de producción, así que realmente son espacios similares en los que estamos jugando y es realmente genial ver cómo todos conectamos las herramientas de manera diferente. Estoy seguro de que esto lo resolveremos a medida que avancemos y crezcamos y esto se revelará. Sí. Ni siquiera me di cuenta hasta que mencionaste que en realidad somos completamente opuestos. Sí. Sí, es gracioso. ¡Increíble! Y así, añadiendo a la mezcla de la comunidad, alguien preguntó si les encantaría escuchar sus pensamientos sobre el uso de herramientas como Bazel para construir aplicaciones web. Y habías hablado mucho sobre el rendimiento increíblemente rápido y que ese tipo de ser el enfoque principal para ambas herramientas.

Y has hablado mucho sobre el rendimiento increíblemente rápido y que ese tipo de ser el enfoque principal para ambas herramientas. Así que la pregunta era, ¿son estas herramientas de alto rendimiento el objetivo final? Permíteme, Fred, continuar. Sí, ahora siento que no soy la persona adecuada para responder a esta pregunta, no tengo experiencia con ninguno de esos sistemas de construcción. Sabes que definitivamente hay algo sucediendo aquí con cómo se conectan, pero sí, no sé lo suficiente sobre ellos para hablar. Está bien, genial.

Entonces, Swix, ¿quieres tomarlo? No. Yo tampoco he usado esos. Está bien, entonces, Evan.

Adelante. Honestamente, no. Solo sé brevemente sobre Bazel porque cuando estaba en Google, sé que esta es esencialmente la versión de código abierto de Blaze, que es el sistema de construcción interno de Google. Pero cuando se trata de, digamos, aplicaciones web, la mayoría del tiempo todavía estás gastando tiempo llamando a tus herramientas del ecosistema, como si estuvieras transpiling React JSX, ¿verdad? Eso no es parte de Bazel. O estás tratando de compilar un archivo de vista o un archivo de hechizo. Esos no son manejados por Bazel. Así que, solo tener una herramienta de construcción que sea rápida no necesariamente, simplemente no constituye el principal cuello de botella en términos de cuando hablas de construir una aplicación web completa, ¿verdad? La agrupación y minificación de JavaScript, todos estos son tipos de preocupaciones específicas del front-end. Bazel es una herramienta de construcción genérica que no se preocupa por estas preocupaciones específicas. Así que, realmente no sé si realmente se aplica en términos de rendimiento general. Diría que solo obtienes este tipo de ganancia de rendimiento tipo ESBuild, salto cuántico, cuando realmente pones todas estas preocupaciones específicas del front-end y las manejas con un lenguaje nativo, ¿verdad?

La razón por la que ESBuild es mucho más rápido en un benchmark de agrupación completa más minificación es porque hace todo esto dentro de Go sin realmente llamar a JavaScript. En el momento en que tienes que usar un plugin de ESBuild para llamar a JavaScript, en realidad ralentiza todo un poco, también. Voy a contribuir un poco aquí, si puedo. Sí, está bien. Así que, el año pasado, en realidad hice un livestream con Minko Gechev del equipo central de Angular, y él mostró un poco de cómo usan Bazel. Y en realidad están más enfocados en construcciones remotas. Ustedes dos están más en la experiencia de desarrollo local, pero para ellos, quieren escalarlo para construcción remota y almacenamiento en caché. Así que, dejaré el enlace a ese livestream allí con la marca de tiempo. Está bien, estoy de vuelta. Me disculpo por eso. Tuve algún tipo de dificultad técnica. Mis disculpas. Hay otra pregunta de la comunidad y no quería tocar casos de uso que no sé cuánto tiempo tenemos. Así que voy a hacer la pregunta de la comunidad porque para eso están aquí las personas. Así que la siguiente pregunta fue, ¿crees que en algún momento Angular cambiará Webpack por alguna otra herramienta de construcción?

Angular tiene su propio ecosistema, pero no parece estar creciendo en uso entre los desarrolladores más nuevos. Creo que si tenemos una herramienta que está profundamente integrada con ese webpack. A menos que lo diseñes desde el primer día para ser agnóstico al empaquetado, no creo que sea un intercambio difícil decir que vamos a cambiar a un empaquetador diferente porque típicamente cuando usas webpack, vas a tener un acoplamiento muy, muy estrecho con cómo funcionan sus plugins, cómo funcionan sus pipelines, vas a depender de muchas cosas específicas que proporciona webpack. Y eso es, creo que realmente no creo que webpack se convierta en el nuevo jquery, sigue siendo una herramienta poderosa y probablemente todavía está funcionando lo suficiente para muchos casos de uso. Y tiene algunas características bastante importantes que otros empaquetadores no tienen, como la federación de módulos, que es algo interesante, que no creo que estén presentando otros empaquetadores en este momento. Así que todavía hay muchas cosas interesantes que pueden potencialmente suceder en webpack. Así que creo que realmente es demasiado pronto para decir que se va a convertir en las herramientas de construcción de jquery, definitivamente, quiero decir, sigue siendo enorme, ¿verdad? sigue aquí para quedarse por lo que puedo decir.