Vite Used to Rely on Two Bundlers. Now It Has One of Its Own.

Why Rolldown is a much bigger story than “builds got faster”

source: https://vite.dev/blog/announcing-vite8

If you have used Vite, you have probably felt the difference before you understood it.

The dev server starts quickly. Hot updates feel instant. You change a component, save the file, and the browser responds almost immediately. For a lot of frontend developers, Vite was the first tool that made modern web development feel light again.

But Vite’s speed was never the result of one magical bundler doing everything.

For years, Vite worked by combining two different tools for two different jobs:

• esbuild made development feel fast.

• Rollup made production builds feel polished.

That architecture was one of Vite’s smartest design decisions. It let the team focus on developer experience instead of trying to build an entirely new bundler from day one.

Now, with Vite 8, that architecture has changed in a major way. Vite now ships with Rolldown, a new open-source Rust-based bundler built by the team behind Vite through VoidZero. The goal is not just faster builds, though that is part of the story. The bigger goal is to unify the entire pipeline.

And to understand why that matters, we need to go back to what made Vite special in the first place.

Development and production are not the same problem

Before Vite, frontend tooling usually treated development and production in a similar way: bundle everything first, then serve it.

That worked, but it also meant larger applications paid a big cost up front. As projects grew into hundreds or thousands of modules, developers started feeling it everywhere: slow startup times, slower rebuilds, and sluggish hot updates.

Vite changed the model.

Instead of bundling the whole application before the browser could do anything, Vite split the world into two parts:

• Dependencies: libraries from node_modules that usually do not change often.

• Source code: your application files, which change constantly during development.

Dependencies were pre-processed with esbuild so the browser could use them efficiently. Your source code, meanwhile, was served directly as native ES modules and transformed only when the browser asked for them.

That sounds simple, but it was a big shift in mindset: Vite stopped forcing development to behave like a production build.

What older dev servers looked like

older bundle-based dev servers bundled the app before serving it.

In the older model, the dev server had to do a lot of work before you could even begin interacting with the app. The bigger the project, the longer the wait.

What Vite changed

Vite serves modules on demand, so the browser loads what it needs when it needs it.

This is why Vite felt so different. Instead of rebuilding your whole world on every change, it let the browser request modules as needed. That made dev startup nearly instant and made HMR much more targeted.

In short:

• esbuild powered the fast path for development.

• Native ESM let Vite avoid unnecessary work.

That was the first half of the story.

So why did Vite still need Rollup?

Because development is not production.

Native ES modules are great during development, but shipping a large app as thousands of separate unbundled modules is still not ideal for real users. Even in a world with HTTP/2 and modern browsers, too many requests still create overhead. Deep import chains still create waterfalls. And production apps still benefit from tree shaking, chunking, minification, and more deliberate output control.

That is why Vite kept Rollup in the stack.

When you ran a production build, Vite handed the heavy lifting to Rollup. Rollup handled the serious bundling work: generating optimized chunks, removing dead code, processing assets, and producing stable production output. It also brought something very important with it: a mature and flexible plugin API that much of the Vite ecosystem grew around.

So the real Vite architecture looked like this:

esbuild for fast development, Rollup for production-grade bundling.

And honestly, that was a brilliant setup. Vite got the speed of one tool and the maturity of another.

Why bundlers still matter, even now

One easy mistake is to assume that because browsers support native ESM, bundlers are becoming obsolete.

They are not.

Rolldown’s documentation makes the case very clearly: bundlers still help in three important ways.

First, they reduce network requests and import waterfalls. If a large application ships as a huge graph of individual modules, the browser still has to request, parse, and coordinate all of them. That overhead adds up.

Second, bundlers reduce total bytes sent over the network. Tree shaking removes code you never use. Minification compresses what remains. Bundled output also avoids repeating import and export overhead across lots of individual files.

Third, bundlers improve JavaScript execution performance. Less code shipped means less code the browser has to parse, compile, and evaluate before the app becomes interactive.

That is the key distinction:

• During development, avoiding full bundling makes the feedback loop faster.

• In production, bundling is still one of the best ways to improve real user performance.

Vite understood that early. That is why it never tried to force one simplistic answer onto both environments.

The downside of using two bundlers

As good as the esbuild + Rollup model was, it came with real costs.

Two bundlers meant two pipelines. Two sets of internal behavior. More glue code. More chances for development and production to behave slightly differently. More work to keep plugins, transforms, and edge cases aligned across both sides of the toolchain.

Over time, that becomes harder to maintain.

The old approach served Vite well, but the complexity of keeping two separate systems aligned kept growing. The architecture that helped Vite move fast early on eventually became something the team wanted to simplify.

That is where Rolldown enters the picture.

Rolldown is Vite’s attempt to unify the stack

Rolldown is not just “another bundler.” It is Vite’s answer to a specific architectural problem.

The idea is straightforward:

• keep the speed expectations developers now have,

• keep the plugin compatibility the ecosystem depends on,

• and remove the complexity of stitching together multiple bundling systems.

Rolldown gives Vite a single unified Rust-based bundler, delivers 10x to 30x faster builds compared with Rollup in benchmarks, and keeps most existing Vite plugins working out of the box.

That combination is what makes this move important.

If Rolldown were only faster, it would be interesting.

If it only preserved compatibility, it would be useful.

But because it does both while giving Vite a more consistent internal architecture, it becomes strategic.

Vite is no longer just orchestrating best-in-class external tools. It now has its own bundling foundation that it can evolve directly. That opens the door to features the team has talked about publicly, including fuller bundle modes, better chunk-splitting control, persistent caching, and tighter collaboration across the Vite, Rolldown, and Oxc stack.

The bigger shift: Vite is becoming a true toolchain

This is the part that matters most.

The story is not just that Vite replaced Rollup. And it is not that esbuild suddenly became irrelevant. Both projects were essential to Vite’s success, and the Vite 8 announcement explicitly thanks them for that.

The bigger story is that Vite has moved from a smartly assembled toolkit to a more integrated open-source toolchain.

Earlier Vite won by choosing the right tools for each stage.

Vite 8 is trying to win by making those stages feel like one coherent system.

That matters for the Vite team because they can evolve the architecture more directly. It matters for plugin authors because compatibility remains a priority. And it matters for developers because the long-term promise is not just faster builds, but fewer weird mismatches between dev and build, better scaling for large apps, and a foundation that can keep improving without carrying as much internal split-brain complexity.

In other words, Vite used to be fast because it knew when not to bundle.

Now it is trying to become even better by also owning the bundler it depends on.

Final thought

The old Vite model was clever: use esbuild where raw speed mattered most, use Rollup where production quality mattered most, and hide the complexity behind a great developer experience.

Rolldown represents the next chapter.

It takes the lessons Vite learned from that two-bundler era and turns them into something more unified, more controllable, and potentially much faster. That is why Rolldown matters. Not because Vite suddenly discovered bundlers, but because it now has one built around the exact tradeoffs that made Vite successful in the first place.

Vite used to rely on two bundlers to feel modern.

With Vite 8, it is betting that one unified open-source bundler can take it further.

Sources

• Vite 8 announcement

• Why Vite

• Why do we still need bundlers?

• Vite dependency pre-bundling guide

• Vite Rolldown guide

• Rolldown homepage