I've been using rolldown-vite for the past 3-4 months with absolutely no issues on a very large monorepo with SvelteKit, multiple TS services and custom packages.
Just upgraded to 8 with some version bumping. Dev server time reduced to 1.5s from 8s and build reduced to 35s from 2m30. Really really impressed.
Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it.
Kudos to the Vite maintainers!
Awesome! been using Vite since its early days. really excited to see how it's improving the JavaScript and TypeScript tooling landscape and how it continues to evolve
Thanks to the Vite team for building a faster, modern bundling solution on a fully open source stack that isn't tied to a specific framework...cough cough, Turbopack
The move from dual-bundler (esbuild + Rollup) to Rolldown as a single unified Rust bundler is exactly the kind of consolidation the JS tooling ecosystem needed. We've been running rolldown-vite on a mid-sized project for a few weeks now and the production builds went from ~35s to under 8s. The real win isn't just raw speed though. Having one consistent transformation pipeline means fewer edge cases where dev and prod behavior diverge, which has been a persistent source of bugs. Curious to see how the full bundle mode shapes up since it promises even faster dev server startup for larger codebases.
Sweet, great job Vite team!
I wonder how much of the Rollup bundling magic has been ported to Rolldown.
One thing that always made this kind of switch to Rust has always been that Rollup has become so sophisticated that's hard to replace with something new.
Ah, wondering how long it will take Angular to replace it's sh*t building tool chain to fully vite compatible, hope it could happen before I change may career path or retire.
> Built-in tsconfig paths support
A great QoL change. One less place to duplicate (and potentially mistake) a config.
Yesterday I stopped hating AI because it converted an old webpack project with impenetrable plugin settings to a single simple Vite config.
I still don't understand how people used to think scripts like this are the proper way to bundle an app.
https://github.com/facebook/create-react-app/blob/main/packa...
vite is great, is all I am saying
I tried it and I saw more than 6x improvement in speed. It's on the top. Awesome tool 1
[dead]
holy shit - Vite 8 - rhymes in french! Did they mention that somewhere?
Outsider question: why use Rollup when Esbuild exist? Is esbuild not enough for production builds?
Congratulations!
Man the perf changes for this version are awesome. Thanks Vite.
Vite 8 is pretty incredible. We saw around an 8x improvement (4m -> 30s) in our prod build, and it was nearly a drop-in replacement. Congrats (and thank you!) to the Vite team!
Same here (10s to 1s). The main reason for this is rolldown [1]. Already had it installed months ago, before it got merged into vite proper. Really awesome stuff.
4 minutes?! How large is that app?
Not meant as a gotcha but I'm surprised because people always tout it as being so much faster than Next. (4m with Turbo would have to be a crazy huge app IME)
Yeah, 4 mins is currently the avg. build time for our TanStack app dockerized. The turbo part takes 30 sec with Vite 7
most likely they are not running the prod build on latest mac. so it is slower.
We saw 12m -> 2m on one of our biggest projects. Incredible really.
It blows my mind that there is a 12m build for a JavaScript application. How may lines of code is this app?
> Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress
Does Oxc also support TS runtime features like constructor parameter properties and enums? I seem to recall in the beta that they had enabled --erasableSyntaxOnly, presumably because Rolldown / Oxc didn't support doing a full transform.
Yes, those work fine: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...
For that matter, TypeScript's version of decorators ("experimental decorators") also works: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...
What's not supported is the current draft proposal for standardized ECMAScript decorators; if you uncheck experimentalDecorators, the decorator syntax is simply passed through as-is, even when lowering to ES2015.
It doesn't support const enum, unlike esbuild which supports them well enough to be credible.
TC39 decorators emit just landed in tsgo about 24 hours ago. Hopefully they're available in Vite 8 soon. I'm using them in GodotJS https://github.com/godotjs/GodotJS/commit/a4bafef9f14c103b09...
Awesome. Standard decorators support is not a dealbreaker for me, but enums and other types of non-erasable syntax would be.
Do you know what the status is on using Rolldown as a crate for rust usage? At the moment most rust projects use SWC but afaik its bundler is depreciated. I usually just call into Deno for builds but would be nice to have it all purely in Rust.
Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent developer desktop, and old slow CI servers were even worse. Now Vite 8 builds it in about a second on comparable hardware. Another demonstration of how much resources we're collectively wasting.
It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.
[dead]
JavaScript was not supposed to a lot of things.
And yet it pays my bills for almost two decades.
If you're already passing over the sources to strip the types, why would you also not do tree-shaking and minifications?
Why would I want to strip my types?
This feels like a ridiculous thread that captures everything wrong with modern Javascript ecosystem.
It's grown into a product of cults and attempted zingers rather than pragmatic or sensible technical discussions about what we should and shouldn't expect to be able to do with an individual programming language.
Another rewrite in Rust.
What about finally stop using node.js for server side development?
I’m with you. It’s very telling when all of the tools are being rewritten and seeing orders of magnitudes of speed ups.
It just shows that people don’t value the actual performance of what they’re running.
isnt that what projects like bun are aiming to do?
Rust works well for toolchains where speed counts and you can control deps, but it's a much bigger ask for server-side app logic where teams lean on JS and its libraries. Switching an established stack to Rust hits hiring and maintenance friction fast, especially with async and lifetime bugs. For Vite's community, requiring plugin authors to redo everything in Rust would probably destroy most of the value users care about.
It has worked perfectly fine with compiled languages until someone had the idea to use V8 outside of the browser.
In fact it still does, I only use node when forced to do so by project delivery where "backend" implies something like Next.js full stack, or React apps running on iframes from SaaS products.
Node as a compiler runtime or node as a runtime runtime?
Anything backend related.
This is for tooling.
Node.js has been extraordinarily useful for building build tools. We're outgrowing it's capacity and rightfully moving to a compiled language. Also faster tooling is essential for establishing a high quality feedback loop for AI agents
Why go halfway, embrace compiled languages in the backend.
Fast all the way down, especially when coupled with REPL tooling.
It takes tooling team and discipline to keep compile times at bay when you reach mid size projects with compiled languages (looking at you Java, C++, Rust).
But, it doesn’t need to be so. Go is pretty fast to compile. So is Jai, from what I’ve seen. So was TurboPascal. Rust has a similar problem to the one Vite has been solving- Rust (and most languages) weren’t designed for compilation speed, and it’s hard to retroactively fix that. But, there’s no reason we shouldn’t have a bunch of statically typed, fast-to-compile languages.
I agree with your remark, only that Rust's current problem is tooling, not the language itself.
See OCaml or Haskell, they also have interpreters and REPLs as part of their tooling.
Also there should be no need to always compile crates from scratch when starting a new project.
Which ironically circles back to your remark of having a similar problem.
Lack of discipline is exactly the magic word regardig the node ecosystem mess.
Maybe? The point still stands that majority of programmers/industry is not equipped to deal with this adequately.
Because writing Rust backend is needlessly complex for majority of projects.
There’s a middle ground between node and rust. Dotnet and Java are wildly productive places to work but they’re not as exciting as rust.
Also, writing JavaScript for the backend is needlessly underperforming for anything with any load.
I've had a great time using Rust with Actix as the framework.
Still easier than dealing with node dependencies, webpack and co, they make me wish to write ASP with OCX components instead.
Your complaint is with Vite – famously incredibly simple and reliable to work with – using Rust, but you're bringing up webpack's complexity?
Node dependencies are fine, add an npmrc file to have it default to exact versioning and you solve 90% of common day to day problems. It's not ideal, but nor is cargo's mystery meat approach to importing optional features from packages.
My remark, and not complaint, is that the fashion to rewrite everything in Rust across the JavaScript ecosystem proves the point of holding it wrong.
Maybe leave JavaScript on the browser, where it belongs.
Awesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.
It's the Vercel way to first run broken previews for several years.
Next started with Turbopack alpha as a Webpack alternative in Next 13 (October 2022) and finally marked Turbopack as stable and default in Next 16 (October 2025). They also ran sketchy benchmarks against Vite back in 2022 [0].
Next's caching has a terrible history [1], it is demonstrably slow [2] (HN discussion [3]), RSCs had glaring security holes [4], the app router continues to confuse and relied on preview tech for years, and hosting Next outside of Vercel requires a special adapter [5].
Choosing Next.js is a liability.
0 - https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...
1 - https://nextjs.org/blog/our-journey-with-caching
2 - https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
3 - https://news.ycombinator.com/item?id=43277148
Next took a very bad turn and double downed on it. Coupled with years of terrible bugs its beyond repair for me unless they rewind a bunch of core changes they did.
There are several much better options right now. My favourite is Tanstack Start. No magice, great DX
+1 for Tanstack start. I just setup a new project with it and like the whole ecosystem. Only slight disadvantage is most third party documentation and automatic setup with packages aren't setup for Tanstack Start yet.
Any suggestions to replace NextJS when you only use static export (no SSR)?
tanstack router
It depends on your application, but for typical SPAs, there are any number of approaches which are better than next by every metric I (personally) care about.
maybe of interest: https://github.com/cloudflare/vinext
(haven't tried it myself)
It's not a good piece of software. Breaks in many places
"Read the announcement: How we rebuilt Next.js with AI in one week".
that makes sense, it's not 1.0 yet
They have the enterprise partners that make Next.js the only officially supported SDK on their SaaS integrations.
See Sitecore Cloud, Sanity, Contentful,....
Really the enterprise partner supports next, but not vanilla js sounds stupid? Honestly I expect them to prioritize nextjs and react given the popularity, but still be open to vanilla js.
I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well.
Are there really anyone who is exclusive to nextjs?
Vanilla JS is "supported" if you write the missing parts, e.g. layout service, visual editing integration,...
In many places they will say it is supported, but when you look into the details only React/Next.js work out of the box without additional work.
A bit like you can deploy Next.js on Vercel, or do it yourself somewhere else.
Got back in to react after a few years’ hiatus and I struggle to even understand what the point of Next is. Bizarrely the official docs even reference Next. Are people using react for non-SPA’s? Why?
Vercel has slowly taken over Facebook's position as being the employer of the main developers of React. There's a debate to be had over how much they 'control' it or not, but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact.
5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export function. It wasn't ideal, but it worked and came batteries included. Over time it's become more bloated, more complicated, and focused on features that benefit from Vercel's hosting – and static builds can't take advantage of them.
These newer features seem of limited benefit, to me, for even SPAs. Why is there still not a first class way of referencing API routes in the client code that provides typing? Once you reach even medium scale, it becomes a mess of inteprolated string paths and manually added shared response types.
Not me, but I can imagine it happening.
JSX is a nice server side templating language. There a lot of people who aren't dependency conscious, and a lot of people who love react, and there is quite a bit of overlap in those two groups. I've used bun + preact_render_to_string for server side JSX templates before and it was nice. When I did it seemed that bun somewhat embraced react, and I could imagine react being the path of least resistance to server-side JSX there for some of the folks in the aforementioned groups.
The point is JavaScript developers rediscovering PHP, Spring MVC, ASP.NET MVC, Rails,.....
And to sell Vercel on top.
I'm being rather snarky here, but the main point of front-end JS UI frameworks is to exist and to survive in their environment. For this purpose they have evolved to form a parasymbiotic relationship with others in their environment, for example with influencers. The frameworks with the best influencers win out over older ones that do not have the novelty value anymore and fail to attract the best influencers.
This could also apply to the recent wave of hate towards Next.
Next is the Microsoft Sharepoint of the JavaScript world. It’s a terrible solution to just about anything, and yet gets crammed into places and forced on people due to marketing-led decision making.
After Tanstack Start, Next.js seems even less intuitive. While it remains a viable option due to its established momentum, it feels quite alien to backend devs, esp with its unconventional defaults.
It feels like Wordpress inasmuch as it’s shoving a tool in places that don’t make sense. React is great for SPAs but if I wanted pre-rendered static content I’d use a different tool.
why? jsx is a great language for templating, the ui being a function of state is an incredible model. i am not a huge nextjs fan but React, mdx and friends are great for pre-rendered static content
I had had a client cancel a job when they heard it's not going to use Wordpress. It was going to be a dashboard showing statistics (air quality, room bookings etc.) from their facility.