- La estructura dual existente de esbuild + Rollup se unifica en Rolldown, un bundler basado en Rust, logrando un rendimiento de build hasta 10~30 veces más rápido
- Se presenta un nuevo registro de plugins que permite buscar y gestionar plugins de Vite, Rolldown y Rollup
- Se añaden funciones para mejorar la experiencia de desarrollo, como Vite Devtools, resolución de rutas de TypeScript, Wasm SSR y reenvío de consola
- Esta versión representa el mayor cambio estructural en el ecosistema de Vite y sienta las bases para la evolución futura de un toolchain unificado
Vite 8 basado en Rolldown
- Vite 8 integra la estructura previa de bundlers duales, esbuild (para desarrollo) y Rollup (para producción), en un único bundler: Rolldown
- Rolldown es un bundler de alto rendimiento escrito en Rust y soporta la misma API de plugins que Rollup
- La mayoría de los plugins existentes de Vite funcionan sin cambios adicionales
- En rendimiento, es entre 10 y 30 veces más rápido que Rollup y soporta funciones avanzadas como caché por módulo, división flexible de chunks y Module Federation
Proceso de adopción de Rolldown
- Al inicio, se ofreció una vista previa tecnológica mediante el paquete
rolldown-vite para recopilar feedback de la comunidad
- Se probó en diversas bases de código reales para resolver problemas de compatibilidad
- Se construyó un sistema de pruebas CI dedicado para plugins y frameworks principales
- En diciembre de 2025 se publicó la beta de Vite 8, integrando por completo Rolldown
- Durante el periodo beta, Rolldown avanzó hasta la etapa de Release Candidate y se estabilizó
Casos reales de mejora de rendimiento
- Varias empresas reportaron reducciones en el tiempo de build
- Linear: 46 segundos → 6 segundos
- Ramp: reducción del 57%
- Mercedes-Benz.io: reducción de hasta 38%
- Beehiiv: reducción del 64%
- Cuanto más grande es el proyecto, más notable es el efecto, y se anticipan mejoras continuas en Rolldown
Toolchain unificado y stack tecnológico
- Vite 8 evoluciona hacia un toolchain end-to-end en el que Vite (herramienta de build), Rolldown (bundler) y Oxc (compilador) colaboran estrechamente
- Se garantiza consistencia en todo el proceso de parsing, transformación y optimización
- Es posible optimizar el tree shaking usando el análisis semántico de Oxc
- La estructura permite adoptar rápidamente nuevas especificaciones de JS
Funciones adicionales
- Vite Devtools: permite analizar visualmente el estado del proyecto desde el servidor de desarrollo
- Resolución automática de rutas (alias) de TypeScript y soporte integrado para emitDecoratorMetadata
- Wasm SSR: soporte para importar
.wasm?init en entornos de server-side rendering
- Reenvío de consola del navegador: envía errores del navegador a la terminal para mejorar la eficiencia del debugging
- @vitejs/plugin-react v6: elimina Babel, aplica React Refresh basado en Oxc y reduce el tamaño de instalación
Dirección futura del desarrollo
- Full Bundle Mode (experimental): realiza bundling incluso durante el desarrollo, logrando inicio del servidor 3 veces más rápido, recarga 40% más rápida y 10 veces menos solicitudes de red
- Transferencia de Raw AST y transformación Native MagicString para reducir la brecha de rendimiento entre Rust y JS
- Continúa la colaboración del ecosistema para estabilizar la Environment API
Cambios en el tamaño de instalación
- Vite 8 aumenta aproximadamente 15 MB frente a Vite 7
- lightningcss (aprox. 10 MB): proporciona compresión CSS por defecto
- Binario de Rolldown (aprox. 5 MB): incremento de tamaño para optimizar la velocidad
- Se prevé seguir optimizando el tamaño en futuras versiones
Guía de migración
- La mayoría de los proyectos pueden actualizarse sin cambios de configuración
- Las configuraciones existentes de
esbuild y rollupOptions se convierten automáticamente
- Para proyectos grandes se recomienda una migración en 2 etapas
- Cambiar de Vite 7 a
rolldown-vite y luego actualizar a Vite 8
- Los procedimientos detallados pueden consultarse en la Migration Guide y el Changelog oficiales
Agradecimiento a Rollup y esbuild
- Rollup proporcionó la base del ecosistema de plugins de Vite, y Rolldown hereda esa API
- esbuild fue una tecnología clave que hizo posible una experiencia de desarrollo rápida y sirvió como impulso para la evolución del tooling basado en Rust y Go
- Las contribuciones de ambos proyectos están profundamente integradas en el ADN de Vite
Comunidad y colaboración
- El desarrollo de Vite 8 fue posible gracias a la colaboración entre sapphi-red y el equipo de Vite, el equipo de Rolldown y numerosos contribuidores de la comunidad
- VoidZero, Bolt y NuxtLabs participaron como socios principales
5 comentarios
Comentarios en Hacker News
Esto hace pensar de nuevo en cuántos recursos de cómputo ha desperdiciado la industria usando sin cuestionarlo herramientas ineficientes, bajo la idea de que “los builds simplemente tardan”
Organizamos los horarios alrededor de esos builds lentos, convertimos los descansos en una especie de chiste y hasta construimos capas de caché
Mis aplausos para los mantenedores de Vite
La mayoría del software en producción es decenas de veces más lento de lo necesario
El hecho de que apps de Electron usen varios GB de RAM y aun así se sientan más torpes que software de hace 40 años es prueba de ello
Hace 14 años me di cuenta de cuánto tiempo se desperdiciaba esperando builds, y sentí que este problema era especialmente grave en el ecosistema Java
Antes, en un proyecto Ruby, las pruebas de integración tardaban 10 minutos cada vez porque recreaban la DB en cada ejecución
Kotlin/Spring Boot también compila lento, y el compilador de Rust tampoco es precisamente rápido
Pero las pruebas sí están bajo nuestro control. Las pruebas unitarias deberían terminar en milisegundos, y las de integración pueden mejorar muchísimo con paralelización y aleatorización de datos
En mi MacBook Pro corro cientos de pruebas de integración de Spring, incluyendo Redis, DB y Elasticsearch, en menos de 40 segundos
Una vez que dejas montado algo así, aparece un bucle de retroalimentación rápido y vuelve la alegría de desarrollar
La parte en la que contribuí a Vite 8 fue el soporte de Wasm SSR
Extendí los imports
.wasm?initpara que funcionen también en entornos SSREl proceso fue lento, pero me impresionó lo detallado que fue el apoyo del equipo, e incluso agregaron documentación
Se nota que el equipo de Vite no solo crea herramientas, sino que también se toma en serio la formación de contribuidores y la colaboración
Da mucho gusto ver esta mejora de rendimiento en la era de Electron
Un proyecto que he mantenido durante mucho tiempo (empezó antes de React hooks) antes tardaba 2 minutos en build con react-scripts basado en Webpack
Ahora termina en 1 segundo con Vite 8. Es un ejemplo de cuántos recursos hemos desperdiciado
El navegador debería poder ejecutarlo tal cual, y TypeScript también fue diseñado para poder ejecutarse directamente con solo quitar los tipos
La mera existencia de estas herramientas de build parece ir en la dirección equivocada
En nuestro equipo, después de adoptar Vite 8, el tiempo de build bajó de 4 minutos a 30 segundos
Fue casi un reemplazo directo, y estamos agradecidos con el equipo de Vite
Lo usamos incluso antes de que se integrara en Vite y es excelente
Dicen que es más rápido que Next, así que si tarda eso debe ser enorme
Gracias al equipo de Vite por crear una solución de bundling open source no atada a un framework específico
(tos ligera al mencionar Turbopack)
Excelentes noticias. Pero no parece que Next.js vaya a beneficiarse de este tipo de logros de la comunidad
Por el síndrome NIH de Vercel
Empezaron con Turbopack alpha en Next 13 y recién en Next 16 lo pusieron como valor por defecto
En 2022 incluso distorsionaron benchmarks comparándolo con Vite
Problemas de caché, rendimiento lento, vulnerabilidades de seguridad en RSC, app router confuso, incomodidades al hospedar fuera de Vercel, etc.
Elegir Next.js es un riesgo
Links relacionados: discusión comparativa, historial de caché, análisis de rendimiento, CVE de seguridad, OpenNext
Incluso en la documentación oficial se menciona a Next como opción por defecto, lo cual se siente raro
No entiendo por qué usar React como no-SPA
Por ejemplo: Sitecore Cloud, Sanity, Contentful, etc.
Con Vite+, Void Cloud, Void Framework, etc.,
parece que ahora empieza el enfrentamiento entre Vercel y Void
En especial, la demo de PRC (Server Functions) es interesante: muestra seguridad de tipos end-to-end desde la DB hasta la UI
Nosotros estamos investigando diseño RPC con Telefunc (una alternativa a tRPC), y esperamos colaborar con el equipo de Void
Links relacionados: video demo de PRC, Telefunc, Vike
Void Cloud parece estar construido sobre Cloudflare Workers, y por ahora hay poca información
Aun así, que Vite+ se publique como open source bajo MIT es muy alentador
Si Bun se enfoca demasiado en el apoyo de Anthropic y descuida el OSS, podría perder ventaja competitiva
Referencia: Void Cloud
Aunque el ecosistema JS sea caótico, Vite sigue mostrando DX sobresaliente y calidad de producción de forma consistente
Con el bundler Rolldown integrado, será una base más rápida y flexible
Como alguien que hace desarrollo web desde 1998, realmente soy fan
Como valoro el mantenimiento a largo plazo, yo uso esbuild directamente
No me gusta tener que arreglar cosas cada vez que wrappers como Vite se rompen por cambios internos
Con Zod manejaba la validación de tipos, y solo generaba código para tipos de Postgres
La próxima vez probablemente usaría Kysely
El soporte integrado para tsconfig paths es una gran mejora de QoL
Reduce la duplicación de configuración
Dependiendo del proyecto, puede ser más simple
En realidad, JS originalmente era un lenguaje que no necesitaba un proceso de build; el navegador debería poder ejecutarlo tal cual, y TypeScript también fue diseñado para poder ejecutarse de inmediato con solo quitar los tipos. La mera existencia de estas herramientas de build parece ir en la dirección equivocada -> ¿cómo se podría normalizar esto?
Como ahora pasó de ejecutarse solo en el navegador a ejecutarse directamente en el servidor, creo que era un paso inevitable.
Creo que es un fenómeno natural que surgió a medida que las aplicaciones web se volvieron más sofisticadas.
Tal vez habría que abandonar el JS del navegador igual que se tiró Flash. Pero no parece que JS vaya a desaparecer.