Vite: Evolution and Future Impact

♪♪ Soy Dominic. No estoy seguro si pueden ver las diapositivas, así que... Sí, ese soy yo. Y mantengo Vite y Svelte. Al menos, trabajo con ambos equipos y hago algunas herramientas, como Vite Ecosystem CI, Vite Plugin Svelte, o TSConfCheck, que todos los que usan TypeScript con Vite también tienen que usar, para cargar archivos de configuración de TypeScript.

Pero esta charla no es sobre mí. También soy freelancer, pero el código abierto es lo que amo. Hoy, les hablo sobre Vite 6 e incluso más allá. En esta charla, les daré una primera visión general de nuestra historia. Ahora hay historia con Vite. Eso es genial. También tenemos un pequeño descanso. Luego se trata de los entornos y lo que tiene para nuestro futuro.

Así que primero la historia. Vite está envejeciendo. Comenzó en 2021 como un lanzamiento público. Y pronto serán cuatro años, pero ha sido un viaje salvaje. Hemos tenido una afluencia masiva de frameworks usando Vite. Y como resultado, también una afluencia masiva de usuarios. Los gráficos de descargas siempre son un placer de ver porque cuando haces código abierto, no quieres nada más que la gente realmente use lo que haces. La gente usa mucho Vite. Ha sido descargado 12 millones de veces a mediados del año. Hoy, esto es 16 millones. El año pasado en esta conferencia, fue descargado 8 millones de veces, ahora son 16 millones. Así que duplicó sus descargas en ese tiempo.

De lo que estoy aún más orgulloso es que este año, superamos los 1,000 colaboradores en el repositorio de Vite. Así que no estamos solos construyendo esto. Somos una comunidad construyéndolo juntos. Y ni siquiera puedo nombrar todos los proyectos que tienen logotipos en esta diapositiva. Y faltan algunos porque se hizo hace unos meses.

Y esto me hace sentir muy, muy orgulloso. Y a todos nos gusta, pero ¿por qué? Estoy llegando a algún lugar con esto, por favor confíen en mí.

Tenemos una gran API de plugins basada en Rollup. La mejoramos con algunos ganchos adicionales. Esto permite a los frameworks construir sus herramientas de una manera muy consistente y fácil. Soporta la renderización del lado del servidor de forma nativa. La renderización del lado del servidor es, bueno, una de las tendencias en los últimos años. Especialmente las aplicaciones híbridas que se hidratan en el cliente después de renderizar la respuesta inicial en el servidor no son solo algo que puedes hacer, sino algo que deberías o debes hacer hoy. Y el soporte incorporado simplemente hace la vida de los autores de frameworks mucho más fácil.

El potente servidor de desarrollo es también una cosa que es increíble de usar. Y puedes construir herramientas de desarrollo que son incomparables en la experiencia del desarrollador. Deberías ver lo que Anthony Fu tiene bajo la manga porque honestamente, este tipo, nos dio Vt Plugin Inspect, que te permite ver lo que otros plugins están haciendo o lo que tus plugins están haciendo. Es súper genial. Y las pruebas con VTest son cero configuración por defecto. Así que no tienes que crear una gran configuración que imite el tiempo de ejecución de tu aplicación para decirle a tu corredor de pruebas lo que debe probar. Simplemente funciona.

La recarga de módulos en caliente, como la reejecución de pruebas de archivos que cambiaste, es un ahorro de tiempo. Probablemente ya me ha ahorrado semanas de mi vida. Y puedes configurarlo con tantas opciones. Como, VTest es uno de los corredores de pruebas más ricos en características que existen. Es, sí, me desmayo cada vez que lo uso. Y las configuraciones predeterminadas integradas en la tubería de construcción de Vt también son geniales. Así que regularmente, las configuraciones de usuario son solo importar algunos plugins, establecer una o dos opciones, y obtienes tu salida. Así que no tienes que hacer mucho como usuario para usar un framework que está construido sobre VT. Y creo que esa es una de las mejores cosas por las que VT es tan amado.

Así que dicho esto, es hora de un descanso, ¿verdad? Funciona. Es amado. Sigue creciendo exponencialmente. Así que hemos terminado. Simplemente montamos el tren del hype y sentimos que lo usamos y no hacemos nada al respecto porque nunca cambies algo que está funcionando, ¿verdad? Pero algunas limitaciones sí se aplican.

Estas limitaciones se van a mostrar en un momento. Con las SPAs, es bastante sencillo en VT. Tienes solo un camino de solicitudes, y el código se envía al navegador. Y tienes solo un gráfico de módulos.

OK, así que se complica un poco cuando añades soporte para la renderización del lado del servidor. Este soporte para la renderización del lado del servidor en VT fue fuertemente inspirado por una versión temprana de SvelteKit que aún usaba Snowpack. Pero básicamente significa que llamas a SSR load module para cargar módulos para la renderización del lado del servidor. Y en los internos de los plugins, esto significa muchas formas diferentes de comunicarse. Tienes, en el lado izquierdo, dos flujos diferentes, uno para el navegador y otro para la renderización del lado del servidor. Y en el ir y venir entre los dos, tienes llamadas HTTP y llamadas a funciones y un web socket. Y es un poco complicado.

Pero incluso peor, tal vez, en el lado del servidor. Así que en el servidor de desarrollo, comparten un gráfico de módulos hasta cierto punto. Así que hay un gráfico de módulos, y tú puedes pedirle que te dé la versión del cliente del módulo o la versión del servidor del módulo. Eso lleva a muchos atajos o código adicional que tienes que escribir cuando construyes frameworks conscientes de la hidratación o SSR que funcionan con la recarga de módulos en caliente durante el desarrollo. Por ejemplo, cuando quieres invalidar un módulo cuando un módulo del cliente cambió, y quieres prevenir que la próxima respuesta de renderización del lado del servidor devuelva un fragmento de código obsoleto e inválido, tienes que invalidar estos módulos por tu cuenta. Este es un código tomado de read-pipe-plugin-serve, por ejemplo. Y en los plugins, en general, el hecho de que estás procesando algo que es SSR se transporta a través de una bandera SSR que se pasa a los hooks en las opciones. Y tienes que verificar y ramificar en ella todo el tiempo. También tienes que pasarla en algunas funciones exportadas que proporcionamos. Así que básicamente eres el mensajero y tienes que lidiar con todo esto por tu cuenta. Y si quieres construirlo, tienes que construirlo dos veces, una para el cliente y otra para la renderización del lado del servidor. Los frameworks pueden envolver, leer y proporcionar su propia CLI para orquestar estas construcciones. O pueden usar un truco que fue popularizado por SvelteKit también pero ha sido usado por Remix y otros. Eso es que usas el hook de right bundle para desencadenar la próxima construcción en una cadena de construcciones. Pero esto es como mucho código repetitivo. Y se rompe. Y construir secuencialmente toma más tiempo. Así que en los años en que hemos estado creciendo, hemos aprendido mucho de nuestros frameworks que nos usan lo que hacen y dónde se encuentran con limitaciones. Y estas limitaciones nos llevaron a pensar qué es.

Y se trata de entornos, realmente. Tienes el navegador. Tienes el servidor. Y podemos solucionar esto. Si miras esto de nuevo, en el lado izquierdo está esta cosa desordenada de Beat 5. Y cuando digo desordenada, no me refiero a desordenada en un mal sentido sino solo en un sentido un poco complicado. Así que si miras a la izquierda con atención y la parte superior e inferior, se ven bastante similares. Es solo como la comunicación en el medio que es difícil y complicada.

Y cuando abstraes eso y dices, oye, tenemos este entorno que ejecuta código en algún tipo de ejecutor. Y luego tenemos un transporte que lo envía al transformador de código en el servidor de desarrollo. Y el framework puede usar el transformador de código. Entonces todo se ve mucho más limpio ya. Pero también puedes tener más de un entorno, ¿verdad? Ya hablamos de SSR y cliente. Y lo que esto significa es que si tienes dos entornos separados, cada uno obtiene su propio gráfico de módulos también. Así que en lugar de esta cosa mixta que tienes que decir si quieres el módulo del lado del cliente o del servidor puedes simplemente pedir el gráfico de módulos del cliente por un módulo o el gráfico de módulos del servidor por un módulo. Y múltiples entornos aún se ejecutan en un servidor de desarrollo que tiene todas estas piezas juntas. Así que el servidor de desarrollo en Beat es como si contuviera todo el contexto y toda la información.

Y con estos diferentes entornos y el ejecutor de módulos, el ejecutor de módulos breve desvío se basa en Vite Node, que es algo que vino de Vitest y fue agregado a Vite Core en Vite 5.1. Permite a Vitest ejecutar tu código y realizar las pruebas en ellos. Pero cuando lo abstraes, puede ser usado para ejecutar cualquier entorno. Y con esto, puedes tener algo que se ejecuta en el navegador, algo que se ejecuta en un proceso de node, y el servidor de desarrollo ejecutándose en un proceso de node. Y todos están separados. Así que antes, el servidor de desarrollo era responsable de la transpilación y resolución de módulos SSR y cliente. Y ahora tenemos este entorno de ejecución separado que está un poco más cerca de cómo se vería tu producción real. Y los plugins para esto, obtienen nuevos hooks, como Config Environment, donde pueden configurar entornos o cambiar la configuración para entornos específicos. Así que si construyes un framework que tiene más de un entorno, puedes usarlo para hacer diferentes cosas en diferentes entornos. Y también obtienen this.environment. Esto es básicamente el gráfico de módulos, la configuración, todos los metadatos para ese entorno están contenidos en él. Así que cada vez que en un hook usas this.environment, obtienes el entorno de esa canalización. Así que la canalización de plugins se ejecuta para cada entorno por separado.

Y un plugin puede participar en ese entorno o no. Y en cada hook, puedes usar el entorno. Así que cuando quieres tener un módulo para tu entorno, simplemente dices this.environment.module graph, obtener módulo. Eso es todo. No tienes que hacer if SSR, if client, if lo que sea. Menos ramificaciones, más claridad.

Y también hay nuevas opciones de configuración. Esto parece inocente. Claro, puedes configurar entornos fácilmente. Pero lo que esto significa es que un plugin que usa un hook de configuración puede agregar nuevos entornos. Así que puedes construir plugins que creen entornos. Aún suena inocente, ¿verdad? Pero esto es súper flexible. Puedes darle a un usuario un plugin que crea cinco entornos y lo que sea. El cielo es el límite aquí. Y no puedo esperar a ver con qué pueden idear todos ustedes, porque no lo sé. Es un área demasiado vasta.

Y también tenemos soporte de CLI. Así que puedes construir todos estos entornos en paralelo o en secuencia dependiendo de cómo estén estructurados juntos. No más encadenamientos extraños y escribir bundle. Y lo mejor de todo, es compatible hacia atrás. Por defecto, vamos a crear entornos de respaldo para cliente y SSR. Así que lo que conoces de Beat 5. Y si traes plugins compatibles con Beat 5, debería funcionar en su mayoría. Hay algunos cambios importantes alrededor de las condiciones de resolución. Pero esto podría llenar una masterclass. Y me enojaría un poco hablar de ello, porque es súper complejo. Así que lo omitiré por ahora. Así que incluso aquí, se aplican algunas advertencias. Pero es mucho más limpio que antes. Y desbloquea nuevas posibilidades.

Como ya mencioné, puedes tener múltiples entornos. Y esto significa que Cloudflare, por ejemplo, un saludo a Dario, por cierto, quien ya ha estado explorando esto, puede proporcionar un entorno de desarrollo que se ejecuta en Miniflare. Hoy, cuando usas Miniflare en Vite, es más como proporcionar hooks y usar un proceso Miniflare separado que se ejecuta junto a tu servidor de desarrollo. Pero con esto, puedes crear un entorno que se ejecuta dentro de Miniflare. Así que está bastante cerca de lo que obtienes de Cloudflare en producción. Y todos los demás proveedores de nube pueden hacer lo mismo.

Pero no se trata solo de proveedores de nube. También es genial para frameworks de aplicaciones multiplataforma. Podrías construir un entorno de desarrollo Tauri o algo para React Native. Puedes usarlo para crear un mejor entorno para construir extensiones web, que luego pueden usarse para construir mejores herramientas web, mejores herramientas de desarrollo para Vite. Y estoy bastante seguro de que más de ustedes tienen ideas sobre lo que pueden hacer con esto. Es súper flexible, y puedes volverte loco. El lanzamiento de esto será pronto, muy pronto. Actualmente estamos probando esto en Ecosystem CI para asegurarnos de no romper nada. Y quedan algunos problemas por resolver. Pero tal vez incluso la próxima semana se lance, y seguro que se lanzará en 2024.

Pero se lanzará con una bandera experimental, porque queremos su retroalimentación, y queremos asegurarnos de que esta API perdure. Como, debería dar la misma experiencia que tenemos hoy, pero mejor. Y con eso, me quedan unos minutos, y quiero hablar sobre lo que viene en el futuro. En 2025, Vite está comenzando un nuevo capítulo. Lo llamo Más es Menos. Queremos estabilizar la API de entorno. Y el elefante en la habitación del que no he estado hablando en absoluto es Rolldown Vite, que desbloquea mucho más. Obtenemos construcciones más rápidas con él, pero rápido y principalmente obtenemos una canalización de desarrollo y construcción más unificada. Porque ahora mismo, el optimizador de desarrollo está usando ESBuild, lo que requiere una canalización de plugins diferente. Así que los plugins de Vite u otros usan un plugin especial de ESBuild para optimizar dependencias durante el desarrollo. Con Rolldown integrado, podemos reemplazar ESBuild con la canalización de plugins regular, y podemos tener una experiencia de desarrollo mucho más rápida y consistente allí también. Obtienes nuevas características. Es más rápido. Y internamente, tenemos menos complejidad, porque solo hay una canalización de plugins.

Así que realmente, realmente parece una nueva era o capítulo para Vite. Creo que podríamos no haber visto lo último de este gran gráfico que te mostré al principio.

Eso es todo por hoy. Hay muchos recursos sobre esto. main.vite.dev te lleva a la documentación. La guía de migración es excelente. Y deberías echar un vistazo a la charla de Patak en Vite Conf sobre la API de entorno y también a la publicación en el blog de Safi Red, porque profundizan mucho más en los detalles. Algunas de las imágenes podrían parecerte familiares cuando vayas allí. También, un registro de cambios, documentación y una guía de migración, por supuesto.

Esta charla ha sido realizada con slide to the left por James. Muchas gracias por hacer esto. Me gusta mucho la DX y UX de esto. Está construido con SvelteKit y Threlt y sería imposible sin Vite. Así que sí, estoy usando las cosas que ayudé a mantener para contarte sobre ello. Y tal vez esto también pueda mejorarse con la API de entorno.

Si quieres ponerte en contacto conmigo, puedes usar Mastodon. Pero no estoy realmente activo en las redes sociales. Así que probablemente sea mejor que vayas a mi sitio web y me contactes allí. También puedes encontrarme en chat.vite.dev. Y en GitHub, soy Dominik G. Haré esta charla disponible en algún momento. Pero podría tomar unos días. Así que publicaré en Mastodon sobre eso.

Tengo que agradecer a algunas personas. Primero, la organización. Lara, has estado haciendo un trabajo increíble gestionando a todos los ponentes. Me siento muy bienvenido aquí. Matthias Oppadack por ser un tipo increíble. Y Vite no sería lo mismo sin él. Todos ustedes, por supuesto, por venir aquí y escucharme.

Es un honor estar aquí. Así que gracias desde el fondo de mi corazón por tenerme. Y estoy seguro de que tienen preguntas. Vamos a empezar.

La primera pregunta para ustedes es, realísticamente, ¿qué tan grande es el problema de que Vite use ES build y rollup? ¿Creen que este es el mayor inconveniente de usar Vite sobre algo como Webpack? Y hemos escuchado que con rolldown, eso podría desaparecer.

Bueno, primero que nada, ES build se usa por su velocidad y su simplicidad. Y Evan Wallace es una de las personas más increíbles. No puedo darle suficiente crédito. Nadie puede, realmente. Lo ha hecho mayormente él solo. Dije que Vite ha usado 1,000 colaboradores. Si miras ES build, es mayormente un solo tipo. No es solo un tipo, pero sí, no puedo agradecerle lo suficiente. Pero para Vite en sí, hay dos diferentes pipelines de plugins. Y el optimizador es diferente del resto, es más complejo, y que eso desaparezca es bueno para Vite.

No quiero hablar de rolldown como una forma de hacer Vite más rápido porque Vite es lo suficientemente rápido. Lo hace más consistente, menos complejo. Eso es lo más importante para mí. La velocidad no es un factor limitante para la mayoría de nosotros. Como, si tienes decenas de miles de módulos, estás dirigiendo una organización. Eres una gran empresa. Tienes enormes intranets y demás. Pero si estás haciendo un sitio web público y tienes decenas de miles de módulos, podrías estar haciendo algo mal. Tenemos una discusión sobre simplicidad versus complejidad más tarde. Únete a mí y discute conmigo sobre esa opinión si quieres. Pero no cambiarás mi opinión.

Genial. Muy bien. Esta siguiente viene de Paolo, y su pregunta es, ¿alguna idea de cómo se planeará el despliegue de rolldown? Rollup es muy sofisticado en estos días, y reemplazarlo en el acto podría ser doloroso. Oh, en realidad, no tengo muchas ideas sobre eso.

Y no sería mi noticia para compartir, así que tengo que deferir a Evan. Él dio una charla en ViteConf. Puedes encontrar el video en línea donde habla sobre parte de ello. Está llegando, y sí, es una gran tarea. Y hay, por supuesto, algunos dolores de crecimiento tal vez. Pero Vite ni siquiera es un adolescente todavía. Como, estamos en la escuela primaria. Así que tenemos algo de tiempo, y se nos permite algo de crecimiento y algo de dolor. Pero el resultado vale la pena. Y también es solo el comienzo.

Esto desbloquea más. Como, la API de entorno combinada con la velocidad añadida y la menor complejidad nos prepara para el futuro. Como, en este punto, Vite es básicamente infraestructura para la web. Y estamos creando más infraestructura después de encontrar lo que nuestros usuarios más necesitan. Y estoy hablando como nosotros y ellos, pero eso no es cierto. Como, hay casi 7 millones de proyectos en GitHub que usan Vite. Vite ha sido descargado casi mil millones de veces ahora. Y es la comunidad haciéndolo por sí misma, realmente. Y eso es lo importante.

Así que mientras hay un impulso que viene de Void Zero y construyendo herramientas alrededor de OXC y roll down, no habría sido posible sin la comunidad. Y siempre será Vite en el núcleo lo que ayuda a cada uno de nosotros a construir cosas geniales. Absolutamente.

Así que esta siguiente es una pregunta que yo también tenía. Así que háblame un poco sobre, como, qué son los entornos y qué va a entrar en su creación. Así que la pregunta de John es, ¿dónde está realmente almacenado el entorno? ¿La API de entorno tiene planes para lidiar con actualizaciones de entornos a través de plataformas? Así que en el corazón de ello, el entorno se define en tu configuración. Así que tenemos una clave de nivel superior de entornos, y luego allí hay entornos nombrados. El almacenamiento se separa por entorno. Y vamos a proporcionar utilidades para que los plugins puedan usar Weak Maps para el almacenamiento en caché para un entorno si trabajan con múltiples entornos. Porque hoy, muchos plugins ponen estado compartido en su contexto de funciones del inicializador, pero eso no funcionará si lo ejecutas en múltiples entornos. Pero esto no será difícil, y en realidad lo hace más consistente que hoy, donde como he mostrado, SSR y cliente están un poco mezclados.

Esta siguiente pregunta es sobre frameworks de front-end. Entonces, con frameworks de front-end como Vue y React añadiendo compiladores para mejorar el rendimiento, ¿cómo juega Vite en esto? Bueno, preguntaste al tipo correcto, porque Svelte ha estado usando un compilador desde hace mucho tiempo. Eso no es obra mía. Rich en algún lugar por ahí hizo la mayor parte. El más nuevo fue hecho por Dominic Gunaway. Pero sí, los compiladores son una tendencia, y los plugins pueden usar compiladores. La API de entorno en realidad hará esto más fácil, porque el compilador de Svelte, por ejemplo, tiene una bandera que se llama Generate, donde puedes decirle si es para una construcción de cliente o de servidor. Y cuando conoces el entorno, puedes simplemente pasar eso. Sospecho que Vite Plugin Svelte perderá alrededor del 10% al 20% de su código cuando nos movamos a esa API. Eso es genial.

Muy bien. A continuación, tenemos, quiero decir, no sé si puedes responder esto, y tal vez sea para el equipo de Next.js pero Anónimo preguntó, ¿eventualmente Vite admitirá la construcción de Next.js? Bueno, Vite admite la construcción de aplicaciones React. Y debido al tamaño del ecosistema de React, React es en realidad el lenguaje más usado para Vite, incluso si eso no es completamente obvio, porque todos los frameworks no están realmente basados en React, excepto tal vez Remix. Oh, lo siento. Olvidé que hay más frameworks que usan React. Algunos estaban en las imágenes. Así que es completamente posible construir frameworks de renderizado del lado del servidor que usen React con Vite. No estoy involucrado en Vercel o lo que planean hacer con Next.js. Así que es posible. Sí, por supuesto. Vite es probablemente el empaquetador más flexible que existe, que es una de las principales razones por las que es tan genial. Así que solo tiene que hacerse, pero no por mí, porque solo soy un freelancer y no tengo los recursos para ello. Definitivamente. Y por mi experiencia, como haciendo la investigación, sé que hay cosas que no son Next.js, pero aún así Reacts renderizados por servidor. Hay como Vinci, que está construido sobre Vite. Y también hay, creo que se llama Waku, que es un framework de componentes de servidor React, pero creo que también construido sobre Vite.

Así que incluso si Next.js no lo está haciendo, otros sí. Sí. Así que Waku fue recientemente añadido al CI del ecosistema de Vite. Así que funciona. Y Vinci es probablemente una de las capas de infraestructura más felices con la API de entorno, porque lo que hicimos aquí es básicamente jugar a su favor. O incluso podría ya no ser necesario hacer todo el trabajo que Vinci está haciendo hasta ese punto, porque puedes usar diferentes entornos en lugar de lanzar diferentes instancias. Genial.

Creo que respondimos esto antes. Así que esta siguiente pregunta es de Semuel. ¿Podrían los próximos entornos usados ser utilizados para construcciones por local? Creo que estamos hablando de internacionalización. Así que si es así, eso podría resolver la división por local de bibliotecas I18N que se pueden agitar como Paraglide.js. No estoy seguro de que esta sea la API o sección correcta para ello, porque la internacionalización apunta a un entorno, así que crear múltiples entornos del mismo tipo. Así que podrías crear múltiples entornos de cliente que todos apunten al navegador, pero usen diferentes condiciones de exportación para marcar un idioma o algo así. Así que técnicamente posible. Pero luego terminas con diferentes salidas y tienes que encontrar una manera de servirlas al usuario y hacer el cambio de idioma. Así que posible, probablemente útil, tal vez no. Pero podría estar equivocado en esto. Es flexible.

Y una de las cosas que acabo de decir que olvidé mencionar antes es que la API de entorno también te permite construir en una versión actual de Node, por ejemplo, pero para una versión anterior de Node. Así que si apuntas a Node 16 por alguna razón inexplicable y deberías actualizar, aún puedes hacerlo porque la abstracción del corredor te permite ejecutar una instancia de Node 16 y usarla. Así que sí, es flexible, pero probablemente no lo usaría para propósitos de internacionalización yo mismo. Eso tiene sentido. Y también, quiero decir, es experimental, así que pruébalo y ve qué sale de ello. Eso es todo el tiempo que tenemos para preguntas. Así que muchas gracias, Dominik. Si tienes más preguntas, asegúrate de dirigirte a la Glass Room. Puedes hacer preguntas en persona. Pero gracias de nuevo, Dominik. Sí, por favor hazlo. Me encanta escuchar de ti. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias.