Vite y el Futuro de las Herramientas de JavaScript

Entonces, hola a todos. Mi nombre es Evan Yeo, y estoy aquí para hablar sobre Vite y el futuro de las herramientas de JavaScript. Bien. Entonces, muchos de ustedes probablemente han oído hablar de Vite. Y así, en los últimos años, ha estado creciendo muy rápido. Y ahora estamos viendo 29 millones de descargas semanales de NPM y más de 1.1 mil colaboradores en GitHub. Y tenemos un vasto ecosistema de herramientas y frameworks construidos sobre Vite, incluyendo probablemente algunas de las herramientas más familiares que han estado usando. Y tenemos empresas que usan Vite o frameworks basados en Vite en producción, incluyendo algunos de los nombres más grandes que hemos escuchado. Y hoy, creo que ya no es una exageración decir que Vite se ha convertido en la capa de infraestructura compartida para la próxima generación de aplicaciones web.

Eso también es mucha responsabilidad. Así que, siempre hemos estado pensando en lo que podemos hacer para que Vite cumpla mejor este papel. Y llegamos a la conclusión de que Vite está lejos de ser perfecto en su estado actual. Así que, hemos estado trabajando arduamente en encontrar qué podemos hacer para mejorarlo desde cero. El mayor problema que vimos anteriormente era que Vite todavía depende de diferentes dependencias con deberes superpuestos. Vite, como herramienta de alto nivel, envuelve un montón de dependencias de terceros, incluyendo ES Build, Rollup. Y a veces, los usuarios también dependen de S3C para la transformación.

Entonces, el problema con esto es que muchas de estas herramientas tienen deberes superpuestos. Están escritas en diferentes lenguajes. Hay muchos problemas de eficiencia cuando pasas datos de un lado a otro entre estas herramientas, y todas tienen un comportamiento ligeramente diferente cuando se trata de empaquetar una transformación. Así que, decidimos construir un empaquetador por nosotros mismos para resolver este problema. Estamos construyendo un empaquetador llamado Rolldown que está diseñado específicamente para Vite para cumplir sus objetivos.

Pero mientras estamos trabajando en Rolldown, comenzamos a profundizar en la pila. Nos dimos cuenta de que para construir un empaquetador, necesitamos también elegir qué analizador usamos, qué AST usamos, qué transformador usamos, qué minificador usamos. Y cuando te adentras en el tema, te das cuenta de que el desafío que enfrenta Vite es realmente un reflejo del ecosistema de JavaScript en general. Así que, si miramos el empaquetador y observamos todas las dependencias de bajo nivel que un empaquetador necesita, nos damos cuenta de que el ecosistema de JS realmente sufre de fragmentación en cada capa. Así que, para analizadores, transformadores, ejecutores de pruebas, enlazadores, formateadores, todas las cosas que usamos en cada capa para cada tarea, hay tantas soluciones diferentes. Y esto solo lleva a mucha fatiga de decisión. Y para el usuario promedio que recién está comenzando en el desarrollo de JavaScript, probablemente no sea la tarea más fácil decidir cuál usar.

Así que, esto no es del todo malo, ¿verdad? El ecosistema de JavaScript fue probablemente uno de los más vibrantes, los más activos. Y esta especie de falta de guía central resulta en una libertad para explorar. Y la abundancia de opciones fue crítica para el ecosistema en los primeros días. Estas soluciones son las que nos ayudaron a llegar a donde estamos. Estamos construyendo aplicaciones de JavaScript más ambiciosas que nunca, y estas son las herramientas que nos ayudaron a llegar aquí. Pero a medida que el lenguaje madura, a medida que llegamos a mucho más consenso y convenciones sobre algunos de estos problemas, esto ha llevado a un impuesto de complejidad para todos. Así que, creo que ahora es un momento en el que JavaScript merece una cadena de herramientas unificada.

Así que, hemos estado trabajando arduamente en este objetivo en VoiZero, que es una empresa que he fundado. Y la misión de la empresa es realmente construir una cadena de herramientas de JavaScript unificada para dar a los usuarios una pila más coherente, una experiencia coherente cuando queremos simplemente entrar en ello y dejar de pensar en elegir y seleccionar un montón de soluciones diferentes. Así que, hay cuatro piezas principales de código abierto en las que trabaja la empresa, incluyendo Vite, Vitest, Rodan y RxC. Y aquí hay una visión más detallada de la pila. Así que, en la parte superior están las herramientas de framework que se construyen sobre el ecosistema de Vite. Vite en sí mismo es obviamente el punto de integración. Muchos de estos frameworks también usan Vitest. Vitest se puede usar solo en cualquier proyecto de JavaScript. Puedes usarlo para probar código de backend. Muchos proyectos que ni siquiera usan Vite también usarían Vitest. Así que, Vite y Vitest interactúan más directamente con frameworks y usuarios finales. Y Rodan es el empaquetador que soporta Vite internamente. Maneja algunas de las tareas de más bajo nivel de empaquetar tu código, optimizar tu código y darte división avanzada de fragmentos, etc. En la capa inferior, OXC es la cadena de herramientas de lenguaje que soporta todas las piezas de nivel superior. OXC en sí mismo incluye el analizador, que está en el núcleo.

El analizador también define el AST que usamos para todas estas otras tareas, como transformación, enlace, formateo, minificación, análisis semántico, etc. OXC también incluye un resolvedor que es compatible con Node.js. El minificador actualmente está en estado alfa. Ya es utilizable. Y el formateador está aún en progreso. Así que, al combinar todas estas piezas juntas, también estamos trabajando en una solución llamada V+. Así que, V está destinado a ser la cadena de herramientas de extremo a extremo que integra todas estas cosas juntas en un paquete más coherente.

Entonces, ¿cuál es nuestra pregunta? ¿Por qué Rust? Si no lo he mencionado antes, todo en las piezas de bajo nivel, tanto OXC como Rodan, están escritos en Rust. Elegimos Rust porque proporciona un buen equilibrio entre el techo de rendimiento y la seguridad de memoria. Y más importante, ya tiene un ecosistema muy activo alrededor de las herramientas JS, por lo que es más fácil encontrar bibliotecas y colaboradores. Tiene una interoperabilidad con JavaScript muy madura a través del excelente proyecto NotPIS.

Y también tiene un soporte muy maduro para WebAssembly, lo que nos permite, por ejemplo, compilar Rodan en WebAssembly y ejecutarlo directamente en el navegador con gran rendimiento. Así que, una nota importante es que no estamos tratando de Rustificar todo. Creemos que hay una buena capa de abstracción donde Rust es realmente bueno para las tareas más bien definidas y sensibles al rendimiento, por ejemplo, transformación, análisis, empaquetado. Pero para los CLIs, para las API de alto nivel que interfazan con el usuario, creemos que requiere iteración constante y flexibilidad, por lo que JavaScript y TypeScript siguen siendo la herramienta de elección para esas capas. Bien, profundizando un poco más en el progreso hasta ahora. En OXC, hemos completado el analizador, el enlazador, el resolvedor, el transformador. El minificador actualmente está fuera de estado, pero ya es utilizable. De hecho, tiene características de rendimiento bastante decentes. Así que no entraré en demasiados detalles para cada uno de los elementos individuales aquí. Pero algunos aspectos destacados. La mayoría de estas cosas que hemos construido son las más rápidas en su propia categoría, incluso comparadas con otras soluciones también escritas en lenguajes nativos. Así que el analizador, el enlazador, el resolvedor, el transformador son todos los más rápidos en su categoría. El minificador es el segundo más rápido, pero también tiene una mejor relación de compresión que la solución más rápida. Así que sigue siendo una opción muy decente.

Así que mantente atento. Algunas métricas adicionales del transformador. Nos enfocamos mucho en optimizar el uso de memoria y el tamaño binario, también. Así que también muestra un gran rendimiento en estas áreas en comparación con otras soluciones.

Y ahora sobre Roldown. Así que hemos estado trabajando en Roldown durante casi un año y medio. Roldown ahora está en estado beta 1.0, lo que significa que ya puedes usarlo casi como un reemplazo directo de Roldown, y verás grandes mejoras de rendimiento. Hemos completado no solo el empaquetado básico, sino también la integración de OXE, lo que significa que Roldown viene con transformaciones integradas para TypeScript, JSX, transformaciones comunes de JS, viene con resolución compatible con node integrada, lo que significa que no necesitas complementos para eso.

Así que esto es mucho más grande en alcance en comparación con Rollup, donde muchas de estas características requieren soporte de complementos externos. También completamos muchas características avanzadas en el empaquetador, incluyendo tree-shaking, define-inject, estas son características presentes en ES build pero no en Rollup, y luego división avanzada de chunks, que es algo que a mucha gente le gusta en Webpack, pero no está presente en ESbuild o Rollup. Esto está implementado en Roldown. También implementamos un soporte de multi-federación. También hemos invertido mucho esfuerzo en la alineación de comportamiento con ESbuild y Rollup.

De hecho, ejecutamos Roldown contra los casos de prueba de ESbuild y Rollup para obtener la mayor cobertura posible donde sea aplicable. Y también soportamos los plug-ins de Rollup de forma nativa. {{^}}De hecho, tenemos un 90% de compatibilidad con la interfaz de plug-ins de Rollup, y la gran mayoría de los plug-ins de Rollup podrán funcionar dentro de Roldown, lo que significa que es un empaquetador Rust, pero soporta plug-ins de JavaScript. Así que Roldown está actualmente ya en beta 1.0, y puedes probarlo si tienes algo que esté usando Rollup actualmente. Y por supuesto, lo más importante en lo que estamos trabajando ahora mismo es en integrar Roldown en Vite.

Antes de profundizar en eso, solo algunos números breves cuando comparamos los números de rendimiento de Roldown en comparación con ESbuild y otros empaquetadores escritos en Rust. Así que Roldown es, hasta donde sabemos, el empaquetador más rápido que podemos imaginar y es incluso más rápido que ESbuild, dependiendo del número de núcleos en tu máquina. Así que el progreso para la integración de Roldown en Vite. Esto es probablemente lo que más les importa a los usuarios de Vite en este momento.

Esto es Vite antes de Roldown. Tenemos un núcleo de JavaScript bastante robusto que incluye el servidor de desarrollo, el contenedor de plug-ins, la API de entorno, etc. Y dependemos de dependencias externas como ESbuild, Rollup y SFSC a través de plug-ins para algunas de las tareas pesadas. Con la integración de Roldown, esto es lo que hemos completado prácticamente en esta etapa, es reemplazar ESbuild, Rollup y SFSC todo con Roldown en sí.

completado prácticamente en esta etapa, es reemplazar ESbuild, Rollup y SFSC todo con Roldown en sí. Así que esto significa que ahora es una pila vertical que Roldown está específicamente diseñado para Vite, lo que significa que podemos enviar más optimizaciones dedicadas para satisfacer las necesidades de Vite. Así que en una futura versión, que también está actualmente en progreso, también enviaremos una versión de Vite que proporciona una opción para el modo Bundle. Muchos de ustedes probablemente saben que el servidor de desarrollo de Vite usa ESM sin empaquetar.

Hace que las cosas sean súper fáciles y flexibles. Hace que la sustitución de módulos en caliente sea fácil de implementar. Pero al mismo tiempo, introduce algunos cuellos de botella de rendimiento cuando tienes una aplicación realmente, realmente grande que necesitas cargar miles de módulos al inicio. El enfoque sin empaquetar en realidad crea un cuello de botella de red que hace que el inicio del servidor sea bastante lento.

Así que el modo de paquete completo es un diseño específico para resolver ese problema. Así que el diseño inicial para el modo de paquete completo está dirigido a grandes aplicaciones de una sola página que están lidiando con problemas de carga de página de inicio del servidor de desarrollo. Así que, la fase uno de hecho ya está disponible. Para cuando veas esta charla, probablemente ya hayamos anunciado el lanzamiento oficial de Roldown Vite.

Así que notablemente, adoptar Roldown Vite es extremadamente fácil porque no requiere cambios de código. Es un reemplazo directo. Así que hemos visto proyectos como ExcalaJAR cambiando a Roldown Vite y obteniendo una construcción 16 veces más rápida simplemente intercambiando el paquete NPM. Así que no hay cambios de código, realmente no hay cambios de conflicto. Simplemente se vuelve 16 veces más rápido. Y dependiendo de cómo esté configurado tu proyecto y dependiendo de la cantidad de plugins personalizados que uses, verás diferentes niveles de ganancias de rendimiento. Pero como mínimo, deberías ver construcciones de 2 a 3 veces más rápidas. Estas son probablemente las aplicaciones más complicadas con toneladas de plugins personalizados. Pero si estás construyendo, por ejemplo, una aplicación pura de React, probablemente verás construcciones más de 10 veces más rápidas.

Así que, ahora profundicemos un poco en Vite+. Mencionamos esto un poco antes, y todavía estamos trabajando activamente en esto. Esto está en etapas muy, muy tempranas, así que estoy hablando principalmente de algo que saldrá en el futuro, pero quiero dar a todos una especie de adelanto para entender hacia dónde estamos construyendo. La idea de Vite es que queremos construir conceptualmente cargo para JavaScript. Si has trabajado con Rust, probablemente sepas que cargo es la cadena de herramientas todo en uno que puede servir a la mayoría de las necesidades del flujo de trabajo de desarrollo durante un desarrollo de Rust. No hay nada como eso en JavaScript, y Vite es exactamente lo que estamos tratando de construir para cumplir ese papel. Así que, curiosamente, queremos diseñar Vite como una actualización directa del Vite existente.

Lo que significa que, si estás usando Vite directamente hoy, actualizar a Vite significa que también solo apuntas a tu gestor de paquetes para alias Vite a Vite+, y estás listo para comenzar. Todo lo que funciona en el Vite de hoy continuará funcionando exactamente de la misma manera, pero la línea de comandos de Vite simplemente se vuelve más poderosa. Ahora viene equipada con comandos adicionales como Vite's lib que está dedicado al empaquetado de bibliotecas, Vite test y bench, Vite linked y format, Vite new para la creación de proyectos, Vite task para la orquestación de tareas de monorepo, y Vite build caching. Viene con las herramientas de desarrollo GUI, viene con auditorías de espacio de trabajo y aplicación de políticas para usuarios empresariales, y probablemente también enviará integración de IA con el servidor MCP incorporado. Así que, quiero profundizar un poco más en algunos de estos comandos de los que hablé, por ejemplo, Vite lib.

El empaquetado de bibliotecas es un tema interesante porque Vite actualmente se envía con un modo de biblioteca Vite, que no muchas personas realmente usan porque hemos estado un poco retenidos en invertir en el comando debido a que el empaquetado de bibliotecas es en realidad un tema bastante complicado en sí mismo. El comportamiento es bastante diferente al empaquetado de aplicaciones. Por eso necesita un comando o un modo dedicado para manejarlo. Así que recientemente comenzamos, recientemente movimos TS-down, un proyecto de Kevin Den, al alcance de Voice Zero y la organización Rodown. Así que TS-down es ahora el empaquetador de bibliotecas oficial basado en Rodown y también es el sucesor de TS-up, que es un empaquetador de bibliotecas muy popular, que ahora ya no se mantiene activamente.

Así que lo interesante que hace TS-down es que viene con generación y empaquetado de TypeScript DTS incorporados. Así que hay dos cosas importantes aquí. Una es que puedes habilitar declaraciones aisladas en tu configuración de TS para permitir que OXC genere tus archivos DTS individuales sin pasar por TSC. Esto hace que el proceso de generación de DTS sea una transformación puramente sintáctica, que es órdenes de magnitud más rápida que generarlo a través de TSC. La segunda es que también implementamos y enviamos un plugin llamado Rodown Plugin DTS que utiliza algunas técnicas personalizadas para poder empaquetar tu DTS en un solo archivo, de modo que no solo reduce el tamaño de distribución de tu paquete sino que también permite que el consumidor de tu paquete pueda verificar los tipos de tu biblioteca más rápido porque TypeScript funciona mejor cuando tiene menos archivos con los que trabajar. Así que también maneja muchas convenciones como múltiples formatos de salida, condiciones de exportación, corrección de manifiesto de parches, linting, etc. Y esto se integrará en VitePlus como su modo de biblioteca.

Un poco sobre pruebas, ¿verdad? Así que ViteTest va a ser esencialmente el comando de prueba de Vite en VitePlus. ViteTest ahora es probablemente el corredor de pruebas de JavaScript más completo en características. Inicialmente, ViteTest nació como una especie de réplica de Jest con la misma API, pero diseñado para Vite. Pero ahora viene con mucho más, así que viene con modo navegador, pruebas de componentes, e incluso características de benchmarking. Una cosa importante que quiero mencionar aquí es cuando estamos evaluando la velocidad del corredor de pruebas. Hay algunos corredores de pruebas, por ejemplo, BounceTestRunner por defecto ejecuta los comandos, ejecuta cada prueba sin aislamiento, por lo que muchas de estas pruebas en realidad comparten estado global, lo que significa que no es técnicamente seguro. Así que si una prueba muta el estado global, puede afectar los resultados de otras pruebas. ViteTest opta por ser seguro por defecto, así que todos los casos de prueba están aislados, forzados a estar aislados por defecto, lo que hace que las cosas, ya sabes, haya una sobrecarga de rendimiento por esto, pero optamos por la corrección sobre el rendimiento en este caso. Puedes desactivarlo si quieres, pero recomendamos desactivar el aislamiento. Linting y formateo. Así que OX-Lint maneja el linting sintáctico, y es 100 veces más rápido que ES-Lint. Las reglas no son tan completas, y actualmente estamos trabajando en un sistema de plugins de JavaScript para OX-Lint, para que puedas escribir plugins personalizados para OX-Lint y potencialmente ser compatible con algunos plugins populares de ES-Lint. Pero en OX-Lint en sí, ya hemos portado la mayoría de las reglas en algunos de los plugins más populares. Otro tema importante que estamos investigando ahora mismo es el linting consciente de tipos. Hay múltiples maneras de hacer esto. Hay diferentes proyectos, por ejemplo, Biome, explorando diferentes direcciones, pero nuestro enfoque a corto plazo actual probablemente será integrar TSS-Lint junto con OX-Lint para servir como el comando de lint en B-plus. Así que TSS-Lint en realidad integra las rutas de verificación de tipos de TSC para implementar reglas de linting durante la verificación de tipos, por lo que solo pagas el costo de TSC una vez en lugar de ejecutarlo nuevamente en tu linter. También estamos investigando activamente la implementación de TS-Go y verificando cómo podemos implementar una interoperabilidad eficiente entre Go y Rust, probablemente usando SyncRPC, para que podamos conectarnos a los diagnósticos de TS-Go en nuestro linting para realizar el linting consciente de tipos con el mejor rendimiento.

Y luego están las reglas estilísticas y el formateo, que actualmente están en proceso. Eso va a entrar en el formato. Y B-plus va a ser consciente de monorepo, lo que significa que tendremos pipelines, orquestación de compilación, almacenamiento en caché, similar a lo de TurboRepo, y tendremos workspaces constantes de primera clase y aplicación de políticas.

También habrá muy buenas herramientas de desarrollo GUI. Si has usado Nuxt, probablemente hayas visto las herramientas de desarrollo de Nuxt, que están hechas por el prolífico Anthony Vu, quien ahora está trabajando en las herramientas de desarrollo para B-plus. Y luego está la configuración de fuente única de verdad que se comparte en todo el repositorio para todos tus comandos. Así que, la resolución de módulos, las transformaciones, respetando la configuración de TS, deberían funcionar de manera consistente y de la misma manera en todos estos comandos.

Y finalmente, quieres posicionar B-plus como un framework para frameworks. Así que si estás activo en el espacio de meta-frameworks, verás que hay muchos frameworks que ahora van con la ruta de framework como un V-plugging. Así que, Remix router, un Remix React router, Ten-Stack Start, Redwood SDK, todos están yendo en esta dirección. Y es una manera muy inteligente de aprovechar V-plus y, ya sabes, las futuras características en V-plus también. Porque en el futuro, cuando envíes tu framework como un plugin de V-plus, también podrás conectarte a estos comandos adicionales. Así que puedes hacer cosas como inyectar reglas de enlace, inyectar maestros de prueba personalizados y entornos, inyectar paneles de herramientas de desarrollo. La posibilidad es ilimitada cuando tienes toda la cadena de herramientas accesible a través de la interfaz de plugins. Dicho esto, V-plus todavía está en progreso. Estamos en las etapas muy tempranas de ello. Así que si estás interesado en dar tu opinión, por favor contacta a void0.dev, hola, y estamos ansiosos por escuchar tus comentarios. Gracias.