Vite: Repensando las Herramientas de Frontend

Hola a todos. Mi nombre es Evan Yeo y soy el autor de Vue.js y Vite. Hoy en esta charla, voy a hablar de Vite, una herramienta de construcción de próxima generación en la que he estado trabajando a principios de este año. Específicamente, quiero discutir algunos de los diseño compromisos involucrados en la creación de una nueva herramienta de construcción, por qué queremos hacer eso y qué implica.

¿Qué es Vite? Vite consiste principalmente en dos partes, un servidor de desarrollo sin paquetes que sirve sus archivos fuente a través de módulos ES nativos, y un empaquetador de producción que se basa en Rollout, está preconfigurado y produce compilaciones de producción altamente optimizadas. ¿Por qué querrías usar Vite en lugar de una herramienta existente? En primer lugar, es ligero y rápido. Realmente rápido. Veremos un ejemplo pronto. En segundo lugar, tiene opiniones propias con valores predeterminados muy sensibles. Se basa en la experiencia que he adquirido trabajando en Vue CLI, que es una herramienta de construcción muy utilizada para proyectos específicos de Vue a lo largo de los años. Similar a una configuración preconfigurada de Webpack y Webpack Dev Server. También es bastante similar en términos de alcance a Parcel. Muchas características comunes como TypeScript, JSX, y PostCSS funcionan directamente. A pesar de tener opiniones propias, sigue siendo muy extensible. Tiene una interfaz de plugin compatible con Rola que facilita la construcción sobre ella.

Entonces, para tener una idea de lo ligero que es, aquí hay un tweet de alguien ejecutando create react app y Vite lado a lado en Replit, que es un servicio que ejecuta tu proyecto en un contenedor remoto. El proyecto Vite es capaz de ponerse en marcha antes de que el proyecto CRA haya terminado de instalarse. Una de las razones por las que Vite es tan ligero es porque se preocupa por su propio recuento de dependencias y el tamaño de la carga útil. En realidad, pre-empaquetamos muchas dependencias innecesarias en Vite para que se instale más rápido. Por lo tanto, el tamaño del disco de los módulos de nodo a menudo es una fracción de los proyectos basados en Webpack. Aquí hay otro ejemplo de un usuario migrando una aplicación Rollup de producción a Vite. Como puedes ver, el tiempo de inicio original era de más de dos minutos y una sola recarga puede tardar hasta 23 segundos. Y ahora ambos números, después de migrar a Vite, se han reducido a casi nada. Concedido, Rollup no tiene reemplazo de módulo en caliente. Pero apuesto a que los usuarios de Webpack no están familiarizados con las actualizaciones en caliente que tardan unos segundos en proyectos grandes. Con Vite, se garantiza que el HMR siempre será instantáneo. Ahora vamos a profundizar en lo que contribuye al rendimiento de Vite. Vite se basa en dos tendencias interesantes que hemos visto en el último año. La primera es que el JavaScript moderno ahora está ampliamente soportado. Los módulos ES nativos ahora tienen más del 92% de soporte global.

Y solo vamos a ver este número aumentar a medida que los navegadores antiguos como IE11 salgan del mercado a un ritmo acelerado. Lo segundo importante es que hay nuevos compiladores de JS escritos en lenguajes nativos. Dos de los ejemplos más prominentes son ESBuild, que está escrito en Go, y SWC, que está escrito en Rust. Ambas herramientas son dramáticamente más rápidas que las herramientas escritas en JavaScript. A veces hasta un 100%... a veces hasta 100 veces más rápido, dependiendo del tipo de trabajo y los núcleos de CPU utilizados.

Así que Vite aprovecha el ESM nativo de CHORN1 construyendo el servidor de desarrollo en torno a los ES modules. Hay muchos beneficios de un servidor de desarrollo ESM nativo. En primer lugar, no hay necesidad de hacer ninguna agrupación. Eso es una gran cantidad de trabajo que simplemente ya no es necesario. En segundo lugar, el ESM nativo es bajo demanda por naturaleza, lo que significa que si un módulo no se carga para la pantalla actual en la que estás trabajando, ni siquiera necesita ser procesado. En tercer lugar, dado que los modules se obtienen a través de solicitudes HTTP, podemos aprovechar las cabeceras HTTP y dejar que el navegador haga el almacenamiento en caché. Y finalmente, lo más importante, el reemplazo de módulos en caliente puede implementarse sobre el ESM nativo de una manera muy sencilla pero eficiente.

Así que veremos si esto nos da grandes victorias en performance pronto, pero quiero ser honesto con los compromisos técnicos aquí. El ESM nativo no es perfecto sin ningún inconveniente. El principal problema que hemos enfrentado es la sobrecarga de las solicitudes HTTP. Por ejemplo, una dependencia como Lodash ES puede contener más de 700 modules internos. Y como el ESM nativo es ansioso, cuando importas incluso solo el método único de Lodash ES, el navegador intentará solicitar todos estos modules que se importan en su punto de entrada. Ahora, cada solicitud de módulo se traduce en una solicitud HTTP y la sobrecarga simplemente se acumula. Crea una congestión de red e incluso en máquinas locales con poca o ninguna latencia, esta sobrecarga sigue siendo notable.

Así que, Vite implementa algunos trucos para solucionar este problema. El primero es que pre-agrupamos las dependencias con ESBuilt. Hay muchas dependencias grandes como Material.UI que contienen cientos e incluso miles de modules internos. Pero no cambian a menudo. En su mayoría contienen JavaScript estándar que no necesita ningún procesamiento especial, a diferencia de tus archivos fuente. Así que, esto los convierte en el candidato perfecto para ser pre-agrupados con ESBuilt. Al pre-agruparlos, podemos asegurar que cada dependencia se traduce en solo una solicitud HTTP como máximo. Y como ESBuilt es tan rápido, el impulso inicial es a menudo dramático, especialmente cuando estás utilizando dependencias grandes. Además, las dependencias no cambian a menudo, por lo que podemos almacenar fácilmente en caché la salida pre-agrupada en disco y saltarnos la fase de pre-agrupación en los inicios de servidor posteriores. Este proceso también convierte las dependencias de JS comunes en ESM para que sean consumibles de forma nativa por el navegador. Además de eso, las dependencias pre-agrupadas pueden ser fuertemente almacenadas en caché con cabeceras HTTP.

Veach reescribe las importaciones a las dependencias para añadir una consulta de huella digital que está vinculada al archivo de registro del proyecto. Así que en las recargas de la página, con un encabezado de caché fuerte, el navegador ni siquiera hará una nueva solicitud a menos que tu archivo de registro haya cambiado. ¿Y qué pasa con los archivos fuente? Dado que los archivos fuente pueden ser editados en cualquier momento, tenemos que revalidar con el servidor en cada solicitud. Pero aún podemos aprovechar las ETags y el encabezado if-modified-since para hacer la solicitud condicional siempre que el archivo en sí no cambie. Esto asegura la realización de recargas completas de la página una vez que el módulo ha sido procesado una vez.

Así que aquí están algunos importantes compromisos de performance en la estrategia del servidor de desarrollo ESM nativo de VEED. En primer lugar, el inicio del servidor es dramáticamente más rápido porque no hay necesidad de hacer ninguna agrupación antes de los inicios del servidor. Y mientras que hay agrupaciones que se hacen para los archivos de dependencia, pero se hacen con ES build, y son típicamente mucho más rápidos que los agrupadores basados en JavaScript, aún así verás un gran impulso. La primera carga de la página de hecho será más lenta porque los modules, tus archivos fuente modules sólo se procesan bajo demanda cuando se solicitan a través de HTTP. Ahora, la sobrecarga de la solicitud también afecta más a la primera carga de la página. Pero en general, si combinas el tiempo de inicio del servidor más el tiempo de carga de la primera página, todavía estamos viendo ganancias muy significativas en casi todos los casos. Una vez que se ha hecho la carga inicial, las recargas completas de la página no se ven afectadas en comparación con un método agrupado. Pero finalmente, otra gran ganancia es que el reemplazo de módulos en caliente en este modelo es dramáticamente más rápido, especialmente en proyectos grandes, porque en el modelo VSM nativo, el rendimiento del HMR performance está desacoplado del tamaño de tu proyecto. Así que incluso a medida que tu proyecto crece con el tiempo, el rendimiento del HMR performance seguirá siendo el mismo.

Tenemos algunas ideas sobre cómo hacer que la primera carga de la página también sea rápida, por ejemplo, introduciendo un almacenamiento en caché persistente para los archivos fuente. Otra idea que podría valer la pena explorar es reemplazar parte de la tubería de procesamiento de módulos internos con módulos nativos compilados. Como ejemplo, Parsel 2 recientemente portó su tubería de procesamiento de data a Rust y ha visto un gran impulso en el rendimiento. Así que hay potencial para que hagamos lo mismo. Pero ambas ideas todavía están en la fase de exploración. Pero estamos seguros de que hay muchas áreas en las que todavía podemos mejorar en este modelo.

Así que ahora hablemos de la construcción para producción. Algunos pueden estar preguntando por qué incluso agrupar para la producción si estamos usando módulos ES nativos? ¿Por qué no simplemente enviar estos módulos sin agrupar a la producción? Bueno, no tengo tiempo para profundizar demasiado en los detalles aquí. Pero la respuesta corta es que el rendimiento no es lo suficientemente bueno por defecto. Y el almacenamiento en caché, que es la supuesta ventaja de la implementación sin agrupar, es muy difícil de hacer bien. La agrupación todavía parece ser el mejor compromiso que cubre más casos. Otra pregunta común es si ES build es tan rápido, ¿por qué V sigue usando Rollup? ¿Por qué no simplemente agrupamos con ES build? Bueno, la razón principal es que la agrupación de aplicaciones orientadas al usuario tiene un conjunto realmente diferente de desafíos en comparación con la agrupación de una biblioteca, que en la mayoría de los casos es solo un archivo único. La división de code es muy importante en la entrega de aplicaciones orientadas al usuario de alto rendimiento. Hasta ahora, en este aspecto, Rollup sigue siendo más maduro y también te da más flexibilidad, más control sobre el proceso de fragmentación cuando se trata de la división de code. Así que esto es importante tanto para nosotros, para darte optimizaciones automáticas, como para los usuarios para poder controlar manualmente el comportamiento final de la división de code. Así que sí, Rollup es más lento que ESBuild, pero en la práctica hemos encontrado que la agrupación real es sólo una parte del costo total de los proyectos del mundo real.

El acto de concatenar los modules juntos, en realidad no es todo el proceso. Por ejemplo, muchos proyectos dependen de transformaciones basadas en JavaScript de modules individuales. Por ejemplo, componentes de archivo único de Vue o Svelte, plugins personalizados basados en Babel para CSS y JS, muchos meta-frameworks necesitan realizar análisis estáticos en archivos fuente. Todas estas tareas normalmente se realizan con herramientas basadas en JavaScript, por lo que incluso cuando se usa ESBuild para la agrupación, todavía tienes que volver a JavaScript para realizar estas tareas, y ESBuild realmente no ayuda mucho en estas áreas.

Otro gran problema en el tiempo de construcción es la minificación. En Vite de hecho, admitimos el uso de ESBuild para la minificación, por lo que puedes obtener compilaciones ligeramente más rápidas a costa de paquetes ligeramente más grandes, pero todavía optamos por Terser por defecto porque Terser, aunque es más lento, todavía proporciona una mejor compresión en la mayoría de los casos.

Lo que obtenemos a cambio al usar Rollup en Vite es que podemos hacer algunas cosas que son actualmente difíciles de hacer con ESBuild. Por ejemplo, la división automática de código CSS. El CSS importado en tus fragmentos asíncronos se construye automáticamente en un archivo separado y se carga en paralelo con el fragmento asíncrono cuando se solicitan. También hacemos una optimización automática de la carga de fragmentos asíncronos. Cuando tienes cascadas en tus fragmentos asíncronos, las aplanaremos automáticamente para ti. También puedes hacer un control manual de la división de fragmentos utilizando las opciones de Rollup. La mayoría de estas cosas no son realmente posibles en este momento con ESBuild. Dicho esto, Vite todavía está abierto a cambiar su agrupador de producción a ESBuild o algo más rápido en el futuro si estas cosas se vuelven posibles, lo que haría que el compromiso valga la pena. Actualmente, estamos optando esencialmente por una compilación de producción más lenta pero un mejor performance para los usuarios finales, lo cual creo que es lo correcto.

Ahora, quiero hablar un poco sobre otro aspecto del diseño de Vite, el hecho de que proporciona una configuración predeterminada opinada y sensata que te lleva bastante lejos de la caja. Si lo pensamos, Vite es esencialmente funcionalmente comparable a una configuración preconfigurada de Webpack con Webpack, DevServer, CLI, CSS Loader, Style Loader, PostCSS Loader, ya sabes a dónde va esto. Esto no quiere decir que Webpack sea malo. Webpack comenzó como un agrupador centrado en JS y tenía que ser básico por defecto y ser extremadamente flexible porque no teníamos convenciones en aquel entonces sobre cómo estas tareas comunes deberían ser abordadas por una herramienta de construcción al construir una aplicación orientada al usuario. Así que tuvimos que inventar estas cosas con el tiempo. Es notable que Webpack sea tan configurable que somos capaces de hacer todo esto con él, ¿verdad? Pero con el tiempo, también nos hemos dado cuenta de que el 90% de las herramientas de nivel superior construidas sobre Webpack contienen una gran cantidad de configuración que aborda exactamente los mismos problemas una y otra vez. La forma en que importamos CSS, la forma en que esperamos que TypeScript y JSX simplemente funcionen, el hecho de que casi todo el mundo tiene que usar post-CSS, ¿verdad? Estas se han convertido en convenciones compartidas entre herramientas y frameworks, a través del ecosistema. Así que Vite reconoce esto. Así que intenta absorber la complejidad de hacer que estas convenciones funcionen de la caja para que el usuario final pueda centrarse en las cosas que realmente importan. También nos damos cuenta de que las convenciones no siempre se ajustan a cada caso de uso. Así que la filosofía de Vite aquí es que optimizamos para el 90% del camino feliz. Mientras que los casos de uso avanzados todavía son posibles a través de plugins, no debería ser un requisito para la mayoría de los casos de uso. Así que también está bien que Vite no cubra todo. No es el objetivo de Vite reemplazar completamente a Webpack. Hay casos en los que Webpack sigue siendo la elección correcta. Por ejemplo, si necesitas federación de módulos. Tiene sentido que diferentes herramientas coexistan y se ajusten a diferentes roles en el ecosistema.

Dicho esto, V todavía ofrece mucho a los usuarios avanzados a través de su potente sistema de plugins. Así que el sistema de plugins de V, lo que llamamos su sistema de plugins universal, es compartido entre el servidor de desarrollo y la compilación de producción. Se extiende sobre la interfaz de plugins muy sencilla de Rollup. Es un superconjunto de la API de plugins de Rollup. Con la capacidad adicional de controlar el comportamiento del servidor de desarrollo, puedes agregar middlewares. Puedes agregar rutas personalizadas. También puedes conectarte al pipeline de HMR. Y finalmente, cuando un archivo cambia, puedes modificar cómo funciona el HMR. Así que esto te da un control muy detallado sobre toda la experiencia de desarrollo.

Además, Vite también proporciona una API para cargar archivos fuente ESM e instanciarlos en Node.js. Con reemplazo de módulo como pre-sistema validation. Normalmente cuando hacemos renderización en el lado del servidor con un bundler, estamos esencialmente ejecutando dos paquetes lado a lado, uno para el cliente y uno para el servidor. Así que cuando editas un archivo, en realidad volvemos a ejecutar ambos paquetes. Pero en Vite, en el lado del cliente, hacemos reemplazo de módulo caliente sobre módulos ES nativos, y en el lado de Node.js, en realidad mantenemos las copias instanciadas de estos modules en memoria, y solo invalidamos las que están afectadas por tus cambios de code. Esto es casi como un reemplazo de módulo caliente en el lado del servidor, que es muy eficiente. Y esto también facilita mucho la creación de una configuración de desarrollo de renderización en el lado del servidor performance con Vite. Ahora, puede ser completamente desacoplado en producción, por lo que no tienes que usar Vite en producción para la renderización en el lado del servidor. Y el resultado es, estamos viendo una plétora de metaframeworks SSR construidos sobre Vite. Hay SvelteKit, Ream, que es un marco de renderización en el lado del servidor para Vue 3. Hay ViteSSR y VitePluginSSR, ambos son extensiones SSR agnósticas de marco en la parte superior de Vite. Y estamos viendo frameworks como Markel, esencialmente usando Vite, que en realidad es capaz de encapsular funcionalidades de metaframework encapsuladas dentro de un solo plugin. Así que esto habla de lo poderoso que es el sistema de plugins.

OK. Así que Vite está creciendo realmente rápido, y estamos muy orgullosos de lo que hemos logrado. Pero también quiero agradecer a los proyectos, estos grandes proyectos Vite se construye sobre ellos, principalmente rollup y ESBuild, ambos son grandes regalos para la community. Y también agradecimientos a proyectos que han inspirado características en Vite, Snowpack, WMR, y Servidores de Desarrollo Web, y Parcel. Hay muchas ideas interesantes en cada uno de estos proyectos, especialmente para Snowpack, WMR, y Servidor de Desarrollo Web. Estamos explorando en el mismo espacio y compartimos muchas de estas ideas. Así que agradecimientos a ellos por inspirar algunas de las características en Vite. Y sí, estoy muy emocionado de ver esta nueva ola de herramientas de desarrollo. Estamos emocionados de hacer avanzar y mejorar la experiencia de desarrollo del ecosistema web juntos. Gracias. Eso es todo. Adiós.

Evan nos ha estado preguntando, ¿utilizas actualmente Webpack o alguna herramienta basada en Webpack, como Next o Nuxt? Y bien, el 52% de ustedes, así que eso es poco más de la mitad, ha estado diciendo herramienta basada en Webpack, así como Next o Nuxt. Evan, ¿qué piensas de esto? ¿Te sorprende esto? Sí. Supongo que la encuesta es un poco confusa porque Webpack basado más Webpack suma más del 100%. No sé, supongo que esto realmente muestra cuán predominante es Webpack en el ecosystem. Obviamente es un gran proyecto, pero sabes, una de las razones por las que personalmente ahora uso Vite para casi todo es porque realmente extraño esa experiencia de desarrollo realmente ágil cuando comencé a hacer proyectos web, sabes, simplemente escribes JavaScript, lo cargas en el navegador y simplemente refrescas.

Todo es bastante rápido, realmente lo extraño. Entonces, ¿te gustaría volver a ese 10% de nada? No nada, ¿verdad? Queremos tener un pastel y comérnoslo también. Pero debería sentirse como esa nada. Eso sería genial.

Entonces, vamos a pasar a las preguntas de nuestra audiencia ahora. Entonces, si tienes alguna pregunta, aún puedes hacerlo en el canal de Preguntas y Respuestas de la Community.

Primera pregunta, ¿hay algún data ya disponible para el rendimiento de Feats en una gran aplicación del mundo real en producción? Sí. Acabo de ver este artículo en dev.to hace un rato. Alguien migró un proyecto con 150,000 líneas de code. Así que esa es una base de code bastante grande de la que creo que era anteriormente Webpack. Así que se mudaron a Vite y estoy tratando de mirar los números. Así que originalmente, un inicio de code usando Webpack era de 150 segundos y la aplicación se carga en seis segundos. Entonces, después de migrar a Vite, un inicio de code es de seis segundos y la aplicación se carga en 10 segundos. Entonces, la recarga en caliente pasó de 13 segundos a un segundo. Y si pones Vite en modo de compilación, el modo de observación de la compilación sigue siendo de 17 segundos Webpack a 13 segundos Vite, por lo que en realidad está ejecutando una compilación completa en cada guardado. Entonces sí, diría que probablemente obtienes 10 veces mejor performance durante el desarrollo en este caso muy específico. Obviamente, variará un poco y creo que esto tiene mucho que ver con cómo su antigua configuración de Webpack estaba usando probablemente Babel completo o TypeScript. También compararon esto cambiando de Babel loader a ESBuilt loader para la transpilación lo que aumentó bastante el performance. Entonces veamos. Eso reduce su velocidad de 185 a 56, lo cual es decente, pero aún no es tan rápido como Vite diría yo. Entonces sí, esos son solo algunos data anecdóticos, pero creo que es una buena referencia. Entonces, supongo que la conclusión es que Vite sí funciona en proyectos grandes y de hecho es capaz de manejar ese tipo de scale.

Entonces, si la gente quiere leer sobre estos números, ¿puedes compartir este artículo en el canal de Discord? Sí, definitivamente. Genial.

La siguiente pregunta es de Jean Cartier y está un poco confundido. Dice, no entiendo. Entonces, ¿podemos usar Vite para construir aplicaciones de react? Sí, absolutamente. Entonces, Vite es completamente agnóstico al framework. Lo creé originalmente porque solo quería obtener un servidor de desarrollo más rápido para mí mismo para usar Vue. Pero a medida que nos acercábamos a la completitud de las características, me di cuenta de que, okay, la mayoría de estas realmente se aplican.

Son agnósticos al framework. Se aplicarían igualmente bien para una aplicación react u otras aplicaciones. Entonces, logré, básicamente, hice una refactorización tratando de pensar, en V2, lo más grande fue que extraemos toda la lógica específica de Vue. Y ese también fue un buen proceso para que pensáramos en la API del complemento. Porque si la API del complemento puede ayudar, puede permitirnos extraer de manera limpia toda la lógica específica de Vue a un complemento, entonces debería funcionar igual de bien para cualquier otro framework. Porque Vue, en términos de la configuración de la compilación, es realmente bastante exigente. Entonces, una vez que hicimos eso, resultó ser bastante exitoso. Ahora estamos viendo a Spelt, como mucha gente está cambiando de Create React App a Vite también. Entonces, sí. Entonces, estoy bastante contento con eso. Porque siento que pusimos todo el trabajo construyendo un servidor de aplicaciones rápido. Lo cual tiene sentido para que pueda ayudar no solo a los usuarios de Vue.

Y una pregunta de seguimiento para mí entonces, ¿sientes, crees que porque estás tan afiliado en tu nombre y tan unido a Vue, eso podría luchar contra la adaptación de Vite? Porque la gente piensa que esto es una cosa de Vue, porque Evan lo construyó. No lo sé. Supongo, sabes, algunas personas son un poco tribales, pero solo pienso que si eres un desarrollador web o un ingeniero, tu objetivo final es usar las herramientas para construir grandes productos para tus usuarios finales. Entonces, ¿por qué importa quién creó la herramienta que estás usando mientras te ayuda a ser más productivo.

Sí. Sí. Sí. Sí. Esa es una gran, gran visión. Y espero que la gente haga eso. Mira las mejores herramientas y, sí, simplemente usa las mejores herramientas.

La siguiente pregunta es de Perú, ¿VITE va a tener algún proceso de construcción de producción más integrado de serie, como la pre-renderización? Si miras nuestro repositorio, tenemos un ejemplo de renderización en el servidor. Así que ese ejemplo ya incluye un script de pre-renderización también. Es bastante simple. Probablemente no vamos a hacer eso de serie. Es una cuestión de alcance, ¿verdad? Así que puedes hacerlo fácilmente tú mismo usando VITE, pero no es algo, porque se vincula a qué framework estás usando, cómo quieres desplegarlo realmente, ¿verdad? Así que VITE no es tan opinado como eso. Esencialmente te damos las API para que lo hagas de la manera que quieras. Considero que ese es el trabajo de los meta frameworks construidos sobre VITE. Supongo que Filekit hace eso, REAM también lo hace. VitePress es un generador de sitios estáticos que construimos sobre VITE. Así que si estás construyendo un sitio de documentación, puedes usar VitePress, que básicamente funciona de serie.

Genial. La siguiente pregunta es de Jack Burke. ¿Cuándo será adoptado Vite por Next.js y Create React? Hazlo realidad ayer por favor. Gracias. Supongo que si estás usando Create React app, puedes cambiar a Vite directamente. Supongo que hay algunas partes de las cosas de Create React app que todavía faltan, como el soporte de Jest, de serie. La integración de Jest ha sido un desafío algo interesante porque Jest no admite transformaciones asíncronas y resolutores de módulos asíncronos. Estos son los tipos de bloqueos que creo que el equipo de Jest está trabajando. Si se resuelven, entonces hace que sea bastante sencillo integrar.

Pero al mismo tiempo, tenemos otras soluciones como Sypress, que pueden ejecutar tu componente directamente en el navegador. Pero aparte de eso, diría que Vite es un reemplazo bastante competente para CRA. Como Repl.it acaba de cambiar de CRA a Vite para todos sus REPLs de React. Y en cuanto a Next, es una historia un poco diferente porque Next está bastante integrado con Webpack. Hacen una precompilación bastante avanzada. Así que imagino que sería difícil para ellos considerar un cambio. También acaban de contratar a Tobias, que es el autor de Webpack. Así que creo que están bastante comprometidos con ese camino, pero sé que están haciendo un trabajo muy interesante para hacer que Next sea rápido también. Quiero decir, Webpack no es necesariamente un callejón sin salida. Creo que mucho tiene que ver con la carga histórica donde la gente simplemente lo sobreconfigura. Pero si puedes, digamos, usar ESBuild para la transpilación, tener optimizaciones muy, muy de primera mano de serie como lo hace Next, todavía puedes obtener un rendimiento bastante decente. Así que estoy interesado en ver cómo se desarrolla esto. Quiero decir, en el mundo de Vue, Nuxt 3 puede ser agnóstico al bundler, por lo que tienen un modo que puede funcionar realmente en Vite. Creo que Nuxt 2 también ofrece una forma de funcionar en Vite ya. He oído hablar de gente que cambió su proyecto actual de Nuxt para funcionar en Vite, y se volvió 10 veces más rápido en desarrollo. Así que, creo que depende un poco de cómo funcionen estos frameworks de nivel superior. Sí. Sí.

Muy bien. La última pregunta que tenemos tiempo para hoy en la Q&A en vivo es de Yatchna. Los principiantes pueden ir a Vite en lugar de React. ¿Eso nos va a ayudar a mejorar nuestro currículum? No lo sé. Vite es solo una herramienta que te ayuda a construir cosas. Creo que es más importante mostrar lo que has construido en lugar de mostrar qué herramientas sabes usar. ¿Verdad? Sí. Sí. También espero que los empleadores miren eso.

Muy bien. Eso es el final de nuestras Preguntas y Respuestas. Pero si tienes más preguntas para Evan, Evan va a estar en su sala de conferencias. Así que allí puedes continuar la conversación sobre cualquier cosa que quieras hablar con Evan. Oh, no tienes una sala de conferencias. Oh, está bien. Lo siento. Lo siento. Sí. Ese fue mi error. Mi error. Lo siento. Pero Evan está disponible en línea. Puedes encontrarlo en todas partes.

Así que Evan, muchas gracias por unirte a nosotros. Gracias. Ha sido un honor tener esta sesión de Preguntas y Respuestas y anunciarte. Esperamos verte de nuevo pronto. Gracias. Adiós. Adiós.