Why use Vite when Bun is also a bundler? - Vite vs. Bun

#vite #bunjs #node #javascript

You might have heard that Bun is not just a runtime, but also a bundler. So you might wonder:

Why do we need Vite or any separate bundler? Couldn't we just make do with Bun?

I've collected the relevant tweets and documentation I've come across, to provide a centralized and searchable answer to this question. Since I couldn't find any, and searching on Twitter sucks.

What Vite uses for bundling.

Vite is a fast local development server / bundler-toolkit. Even though it touts that it lets you do unbundled development (by way of ESM), the devil is in the details. In production especially, Vite does use a bundler to create the bundle of JS that the client receives. It currently uses two bundlers, actually.

In your local development environment, Vite uses a bundler called esbuild to pre-bundle dependencies and convert them into ESM (to enable quick hot starts and hot reloads when you develop). Since Vite uses ESM when you work (instead of creating and always re-creating a client bundle when you update the code) this is what you've heard as unbundled development.

For production, Vite uses the slower JS-based bundler Rollup to create a small client side JS bundle (for faster download), and for potential plugins that use Rollup's flexible API. Even though Vite uses ESM in development environment, for speed (since network latency is not an issue there). But in production Vite can also use esbuild to speed up transpilation and minification. In the future Vite may use esbuild entirely for bundling in production instead of Rollup, due to the speed it would gain.

Update 2023-10-05:

Rolldown (a Rust based bundler) will replace Rollup and esbuild in Vite. Why Rolldown? Mainly to get faster production builds ('the speed of esbuild, but not only for the dev env') while also preserving the flexible API of Rollup. By consolidating into using Rolldown as a single bundler then Vite will also enforce better consistency between dev and prod environments. More in the launch presentation for Rolldown.

Bun is many things, also a bundler.

Bun is not just a Node replacement, but a Zig port of esbuild (initially the same fast algorithm), so includes it's own (currently limited) bundler:

But what about the apparent overlap between Bun and Vite? Since you can use Bun as a bundler (Bun's author Jarred addressed the issues on HN). Why is Vite still needed?

The answer: Why Vite is still needed.

In short, Vite's creator Evan You answered the question here:

So, you can run Vite on Bun, no problem. Bun has fully supported Vite since Bun v0.7.

With the current caveat:

While Vite currently works with Bun, it has not been heavily optimized, nor has Vite been adapted to use Bun's bundler, module resolver, or transpiler.

So, currently, the distinction stands that:

Bun is awesome as a Node.js replacement for the server (as a JS runtime).

Vite is great for unbundled fast development, and for flexible and optimal bundling of the JS code in production which is sent to clients over the network. Vite has API's that many developers love, and thus it already has a good ecosystem.

Vite has Hot Module Reloading (HMR), which is important for fast local development. Bun's HMR currently has at least one open issue.

Bun's HTTP server doc currently has a note regarding HMR:

Note — In a future version of Bun, support for Vite's import.meta.hot is planned to enable better lifecycle management for hot reloading and to align with the ecosystem.

In short: Bun won't replace Vite in the near future. (This might be some famous last words, given Bun's author Jarred's productivity, though!)

The future?

It's hard to say for the long term future. But my guess is that people will use Vite with Bun under-the-hood, but that Bun slowly will incorporate a lot of Vite's API's, so that in the end Bun will be all you need in one place. It seems to fit with Bun's vision of being "a fast JavaScript all-in-one toolkit", as their landing page states.

But my guess is that Vite will still be "Next Generation Frontend Tooling" for a while. If only for all of the projects that will still run on Node, due to:

Developer caution and inertia (even Vite is new to many!).
Bun's current compatibility issues and bugs.
Bun's currently 5% missing Node API's might be a blocker for some.
The current lack of Bun support on Edge network environments. I.e. Cloudflare Workers is it's own JS runtime that use V8 isolates (like Chrome tabs). Whereas Bun uses JSC instead of V8, and Bun plans on building it's own Edge network hosting, custom hardware distributed globally and all. That may take a while. Also, AWS adding Bun as a native runtime is currently an open question, which would be needed to reduce cold starts.

Do you think Bun will replace Vite in the medium to distant future, and if so, why? Share your thoughts in the comments.

Alternate article titles: Vite vs. Bun comparison. Bun vs. Vite comparison.

Top comments (9)

Hussein Kizz • Sep 20 '23

I think it's just too early to judge bun, it's still new and therefore has a lot of room for improvement, for example what woul bun 5 or 10.0 look like we should ask, let's not judge it now, the idea of having an all in one tool that handles the common js, es complexities is much more exciting for me and needs more exploration!

eerk • Dec 27 '23 • Edited

Thanks for this article, I was confused by Bun's own page and their statements that Bun can also be used for front-end development and front-end module bundling, while at the same time they don't give any clear examples. Manually adding Bun to Vite seems a bit unnecessary at the moment.