Build Tools Compared 2026 — Vite, Webpack, Turbopack, Bun

Every JavaScript project hides a quiet piece of machinery between the code you write and the files a browser receives: the build tool. For most of the 2010s that meant webpack. In 2026 the field is split three ways. Vite is the general-purpose default, Turbopack comes built into Next.js, and webpack is still the most-used tool in the State of JavaScript survey while scoring far lower on satisfaction. This article explains how each one works, where each wins, and which published numbers can be trusted.

The short answer: which build tool for which job

If you only need a recommendation, the table below is the 30-second version. The rest of the article explains the reasoning, so you can disagree with it for your own project.

Situation	Reasonable default	Why
New Vue, Svelte, Solid, or plain TypeScript app	Vite	Fast dev server, small config, huge plugin ecosystem
New React single-page app without a framework	Vite (or a framework)	The React team no longer recommends Create React App
Next.js app	Turbopack	Default bundler since Next.js 16; opt out with --webpack
Large existing webpack codebase	Keep webpack, or move to Rspack	Rewrites rarely pay for themselves; Rspack is webpack-compatible
Microfrontends using Module Federation	Webpack (or Rspack)	The feature was designed around webpack builds
Server runtime, scripts, and bundling in one binary	Bun	Runtime, package manager, and bundler ship together
Publishing an npm library	tsdown, or Rollup	tsup is no longer actively maintained

The pattern is that the framework usually picks the bundler for you. Next.js ships Turbopack, SvelteKit and Nuxt sit on Vite, and Create React App (webpack underneath) has been retired. The genuine choices are left for teams building their own setup, which is rarer than it was five years ago.

What a build tool actually does

Browsers read HTML, CSS, and JavaScript. They do not read TypeScript, JSX, Sass, or a project with 3,000 files that import each other. A build tool closes that gap. It reads your entry file, follows every import to build a map of what depends on what (the dependency graph), transforms each file into something a browser understands, and writes the result to disk.

Think of a restaurant kitchen. During development the kitchen cooks to order: you ask for one dish, and only that dish is prepared. In production the kitchen preps a banquet: everything is cooked ahead, packed into a few trays, and shipped. Different tools disagree mainly about how much of the banquet to prepare before serving the first plate.

Four jobs get bundled together under the name "build tool", and it helps to separate them:

• Transforming converts TypeScript, JSX, and modern syntax into plain JavaScript, and compiles CSS.
• Bundling merges many modules into a few files, because every extra file is another network request.
• Optimizing removes unused code (tree shaking), shrinks names and whitespace (minification), and splits code so each page loads only what it needs.
• Serving runs the local dev server and swaps changed code into the open browser tab (hot module replacement, or HMR) without a full reload.

A tool can be excellent at one and mediocre at another. That is why "Vite vs webpack" is a slightly slippery comparison. Vite's dev server and its production bundler are, historically, two different engines with one configuration file on top.

Vite: the default that skips bundling in development

Evan You, who also created Vue, released Vite on April 20, 2020, according to Wikipedia's project history. It is now maintained with backing from VoidZero Inc. The one-sentence idea is that a dev server does not need to bundle your app before showing it.

How the dev server works

Vite pre-bundles your dependencies once, because libraries rarely change. Your own source code is served on demand over native ES modules (ESM, the import syntax browsers understand directly). The browser asks for a file, Vite transforms that one file, and sends it back. When you edit a module, only that module is replaced in the browser. The official Vite guide describes this as the reason startup stays nearly instant regardless of app size.

The restaurant analogy applies directly: nothing is cooked until someone orders it. For a large app where you are touching one screen, that laziness is a big saving. A deeper walkthrough of this model is in our Vite explainer.

The same guide is candid about the trade-off. Unbundled serving can slow down very large codebases, because the browser fires a high number of separate requests, and the Vite team has said it is exploring a dev mode that bundles more like production. Production builds are bundled anyway, because shipping unbundled ESM costs extra network round trips from nested imports. Picture moving house: carrying every item through the door one at a time works when you own a toaster and a lamp, and fails when you own a library.

What changed with Vite 8 and Rolldown

Until 2026, Vite used esbuild during development and Rollup for production. Two engines meant occasional behavior differences between dev and build. Vite 8, which became stable on March 12, 2026, replaces both with a single Rust-based bundler called Rolldown, built by the VoidZero team. The Vite 8 announcement claims builds up to 10 to 30 times faster than Rollup while keeping plugin compatibility.

The announcement also lists production build reductions reported by companies during the preview and beta period. These are self-reported and workload-specific, but they give a sense of scale:

Company	Reported change
Linear	Production build from 46 seconds to 6 seconds
Ramp	57% reduction
Mercedes-Benz.io	Up to 38% reduction
Beehiiv	64% reduction

Source: Vite 8 announcement, March 12, 2026. Figures are reported by the companies, not independently measured.

Practical details matter more than headline multipliers. Vite 8 requires Node.js 20.19+ or 22.12+, the same as Vite 7. A compatibility layer converts existing esbuild and rollupOptions settings to their Rolldown equivalents. Install size grows by about 15 MB, mostly from lightningcss and Rolldown. For large or unusual projects, the Vite team suggests a two-step upgrade: first try the rolldown-vite package on Vite 7 to isolate Rolldown-specific problems, then move to Vite 8.

Where Vite is weaker

Vite does not do everything for you. It is a build tool, not a framework, so routing, data loading, and server rendering come from whatever sits on top. Its plugin ecosystem is strong but younger than webpack's, which means a few edge-case loaders have no direct equivalent. And because the dev server relies on browser-native module loading, behavior in development can differ in subtle ways from the bundled production output, a gap Rolldown is meant to narrow.

For more on where Vite fits among everyday front-end choices, see our roundup of web development tools.

Webpack: still the most used, no longer the default

Webpack is a module bundler created by Tobias Koppers and now maintained mainly by volunteers, according to its own roadmap. Its core idea, treating every file type as a module that loaders can transform, made it the standard for years. Webpack 5 was released on October 10, 2020, and the project is still shipping: version 5.112 appeared in October 2026, according to the webpack blog.

The State of JavaScript 2025 survey, run in November 2025 and published in February 2026, shows the odd state of affairs. InfoQ's coverage reports webpack at 87% usage and Vite at 84%, with Vite at 98% satisfaction and webpack far lower (InfoQ gives 26%, down from 36% in 2024; other summaries of the same survey quote a different webpack figure, so treat the exact number as soft). The survey's own build tools page says its authors "thought this would be the year Vite finally overtakes webpack" and that the overtake will have to wait one more year.

The same page lists configuration as the biggest pain point for build tools overall, with 329 mentions, and webpack as the most-named tool in the pain-point answers (99 mentions against 57 for Vite). Usage that high with satisfaction that low describes inertia: many projects use webpack because it is already there.

What webpack still does best

Module Federation is the standard example. The webpack documentation describes it as a way for multiple separate builds to form a single application, where each build can expose code to others and consume code from them at runtime. One build acts as a host and others as remotes, and shared modules such as React can be loaded once instead of bundled several times. Teams that split a large product into independently deployed pieces built this way have the deepest tooling on webpack.

Webpack also remains the most configurable option. If your pipeline needs unusual chunking rules, custom loaders, or integration with older enterprise tooling, the flexibility is real, and so is the cost of describing it in webpack.config.js.

Where webpack is heading

The webpack team published a 2026 roadmap on February 4, 2026. Its planned work aims at easier use and at a future webpack 6, with many items landing first as experimental features. Planned items include native CSS Modules support (replacing plugins such as mini-css-extract-plugin), TypeScript transpilation without separate loaders, HTML files as entry points, a universal target that outputs pure ESM for Node, browsers, Bun, and Deno, and a multithreading API for parallel work. Several of these copy conveniences that Vite popularized. The roadmap also says donations and sponsorships are crucial to the project's sustainability.

Our reading: webpack is not dying, but it is moving toward the defaults its competitors already offer, while the speed gap is being closed from outside by Rust-based tools that accept webpack's configuration, covered below.

Turbopack: the bundler you get with Next.js

Turbopack is an incremental bundler written in Rust, built into Next.js. Unlike Vite, it does not skip bundling in development. The Next.js documentation says some tools rely on the browser's native ESM in development, which works for small apps but can slow large ones down through excessive network requests. Turbopack bundles in development, but lazily: it compiles only what the dev server is asked for.

Its second trick is caching. Turbopack parallelizes work across cores and caches results down to the function level, so work already done is not repeated, and results can persist to disk between runs. Think of a kitchen that keeps every chopped onion labeled in the fridge instead of starting from whole vegetables each morning.

A timeline of how it became the default

It is easy to assume Turbopack became the Next.js default in version 15, but that is not quite right. Per the documentation's version history:

Next.js version	Turbopack status
15.0.0	Stable for next dev
15.3.0	Experimental support for next build
15.5.0	Beta support for next build
16.0.0	Stable for builds, and the default bundler

Next.js 16 was announced on October 21, 2025. Its release post claims 2 to 5 times faster production builds and up to 10 times faster Fast Refresh, and says more than 50% of development sessions and 20% of production builds on Next.js 15.3+ were already running on Turbopack at that point. Those are Vercel's figures for Vercel's own benchmarks, a point we return to below. Apps with custom webpack setups can still opt out with next dev --webpack and next build --webpack.

If you want the wider picture of what Next.js 16 changed beyond the bundler, our Next.js developer guide covers the App Router and Server Components, and the Next.js vs React comparison helps decide whether you need the framework at all.

The limits worth knowing before you migrate

The Turbopack docs list the differences from webpack plainly:

• No webpack plugins. Webpack loaders are supported; plugins are not. Anything integrated through the plugin system needs an alternative.
• A webpack() function in next.config.js is ignored. Configuration moves to the turbopack key.
• Lightning CSS compiles your CSS, which uses five digits of decimal precision where webpack uses ten. The docs give the example line-height: 1.47059 against 1.4705882353, and warn about subtle rendering differences.
• Custom Sass functions (sassOptions.functions) are unsupported, because Turbopack's Rust core cannot run JavaScript functions passed in.
• Yarn Plug'n'Play is not planned for support.
• It does not type-check. Run tsc --watch or rely on your editor, as the docs advise.

The State of JavaScript commentary adds a human note. Turbopack's usage shows "a lot of progress," in the survey authors' words, but its satisfaction ratio is "quite worrying." The InfoQ report puts its usage at 28%, and since it is a default rather than a deliberate pick for many of those developers, the usage figure says little about preference.

Bun: a runtime that also bundles

Bun is easiest to misjudge when you file it next to Vite. It is a JavaScript runtime (an alternative to Node.js), a package manager, a test runner, and a bundler in one executable. The bundler was announced in May 2023, and Bun 1.0 was released on September 8, 2023, according to the Bun blog.

The biggest recent news was not technical. On December 2, 2025, Bun announced that it was joining Anthropic. The announcement says Bun remains open source and MIT-licensed, is still developed in public by the same team, and had passed 7.2 million monthly downloads in October 2025. It also says Claude Code ships as a Bun executable. Our Claude Code explainer covers the product side. For build-tool decisions, the relevant fact is that Bun has a well-funded, committed maintainer, which matters for a tool you may bet a deployment on.

What the bundler does

The bundler documentation describes a native bundler for JavaScript, TypeScript, JSX, and other file types, run with bun build or the Bun.build() API. It supports code splitting, minification, source maps, plugins, watch mode, and standalone executables. It processes HTML files and bundles the scripts, stylesheets, and images they reference. A command looks like this:

# Bundle an entry file into ./out
bun build ./index.tsx --outdir ./out

# Several entry points with code splitting
bun build ./entry-a.ts ./entry-b.ts --outdir ./out --splitting

Two limits show up in the docs. Bun does not generate .d.ts type declaration files, so libraries still need tsc for those. And the docs cite esbuild's three.js benchmark but present the results only as a chart, so there are no timings in the text to quote. A blanket claim such as "5 to 30 times faster" for everything Bun does is not supported by anything on that page, so it is better to benchmark the specific task you care about.

When Bun fits

Bun fits best where the runtime and the toolchain are the same decision: new back-end services, scripts, command-line tools, and projects that want TypeScript to run without a separate step. As a replacement for Vite on a large front-end app, it is a thinner bet. Its 1.3 release in October 2025 added zero-config frontend development, and the State of JavaScript commentary said Bun is "doing quite well across all categories," but a front-end team needs the plugin ecosystem, framework integration, and documentation that Vite has accumulated.

Rspack, Rolldown, esbuild, Parcel, and the rest

The headline tools are not the only ones. Several others explain where the field is going, because they are what the big tools are built from.

Tool	What it is	Why it matters
esbuild	Fast bundler with built-in support for JavaScript, CSS, TypeScript, and JSX	Set the speed expectations; many tools use it or imitate it
Rolldown	Rust bundler from VoidZero, with Rollup-compatible APIs and esbuild-like scope	Powers Vite 8
Rspack	Rust bundler from ByteDance that modernizes the webpack API	Faster path for webpack projects
Rsbuild	Build tool powered by Rspack, with a Vite-like out-of-the-box experience	Alternative for teams who want Rspack without hand-written config
Parcel	Zero-configuration build tool with Rust-based compilers	Still named by the React team as a build-tool option
tsdown	Library bundler built on Rolldown	Successor path for tsup users

Rspack: the webpack escape hatch

Rspack deserves its own explanation because it solves a different problem than Vite does. The Rspack introduction says it was created at ByteDance because production builds of large monolithic apps sometimes took 10 to 30 minutes. Rspack 1.0 arrived in August 2024. It covers most of webpack's APIs, works with almost all community loaders, and the docs report that more than 85% of the 50 most-downloaded webpack plugins either work in Rspack or have an alternative.

For a company with years of webpack configuration, that is the practical migration route: keep the mental model and the config shape, change the engine. Teams that want a Vite-like experience on the same engine are pointed to Rsbuild.

esbuild and its benchmark

The esbuild site states its goal as bringing "a new era of build tool performance" and claims that existing web build tools are "10-100x slower than they could be." Its published benchmark bundles 10 copies of three.js from scratch with minification and source maps:

Tool	Time reported by esbuild
esbuild	0.39 s
Parcel 2	14.91 s
Rollup 4 + Terser	34.10 s
webpack 5	41.21 s

This is the project's own benchmark, run on a synthetic workload. It is useful as a comparison of raw bundling throughput, and not much more.

Parcel and the abandoned-tool myth

A common claim is that Parcel is "largely abandoned." The evidence points the other way: the React team still lists Parcel, along with Vite and Rsbuild, as a build tool for people with unusual constraints. Parcel describes itself as zero-configuration, with JavaScript, CSS, HTML, and SVG compilers written in Rust. It is a smaller player than Vite, and the State of JavaScript commentary does not single it out, but "niche" is a fairer word than "abandoned."

What the benchmarks do and do not tell you

Tables of "real numbers from a medium React app" circulate widely, and most have no named source or method. Here is how to read the numbers that do have sources.

Four figures appear above: Vite 8's company-reported build reductions, Vercel's 2 to 5 times Turbopack claim, esbuild's three.js benchmark, and the "up to 10 times" Fast Refresh claim. Each measures something different.

• Cold versus warm. A cold start builds everything from nothing. A warm start reuses a cache. Turbopack's function-level caching, and any tool's disk cache, change the answer dramatically between the first run and the tenth.
• What is included. Type checking, minification, source maps, and CSS processing can each add or remove seconds. esbuild's benchmark includes minification and source maps; a dev-server "ready in 300 ms" figure often includes none of the production work.
• Whose project. Vendor benchmarks are run on workloads chosen by the vendor. Company-reported numbers, such as Linear's 46 seconds to 6 seconds, describe one codebase and one migration, in which other changes may also have shipped.
• The metric that matters to you. Developers feel HMR latency dozens of times a day, but they feel cold start only when opening the project. CI cares about production build time and cache hit rate.

A worked example, with assumptions shown

Here is how to estimate whether a tool switch pays off, using placeholder numbers you should replace with your own measurements. Suppose a developer saves a file 150 times a day, and the HMR wait is 1.5 seconds on the current tool against 0.2 seconds on a faster one. The difference is 1.3 seconds per save, or 195 seconds, a little over three minutes per day. Across 20 developers and 220 working days that is roughly 237 hours a year.

Notice what the calculation leaves out. Waiting under a second or two is a different experience from waiting ten, and nobody has a trustworthy conversion from seconds to flow. So treat the figure as an upper bound on direct time savings, not a forecast. The more reliable benefits are usually less glamorous: a smaller config file, one fewer plugin to maintain, and a CI step that finishes while the developer is still in context. The web performance optimization guide explains how build output ends up affecting what users experience, and why web performance affects SEO covers the search side. Faster builds do not make faster sites by themselves. Smaller bundles do.

How to benchmark your own project

Measure on your own code, on the machine and CI runner you actually use. Record four numbers separately: dev server ready time, time from saving a file to seeing the change, production build time with an empty cache, and production build time with a warm cache. Run each several times and keep the median. Check the output too: bundle size and chunk count matter more to users than build time ever will.

Side-by-side comparison

	Vite 8	webpack 5	Turbopack	Bun bundler	Rspack
Written in	JavaScript/TypeScript with Rolldown (Rust)	JavaScript	Rust	Native code	Rust
Dev model	Native ESM, on-demand transforms	Bundles up front, HMR	Bundles lazily, function-level cache	Built-in frontend dev server	Webpack-style bundling, incremental
Works outside its home framework	Yes	Yes	Built into Next.js	Yes	Yes
Plugin ecosystem	Large, Rollup-compatible	Largest	Loaders only; no webpack plugins	Smaller, growing	Most webpack loaders; many plugins
Config effort	Low	High	Near zero in Next.js	Low	Medium (webpack-like)
Best fit	New apps, libraries of apps	Legacy apps, Module Federation	Next.js apps	Runtime-plus-tooling projects	Large webpack migrations

Migrating without breaking things

Build tool migrations fail in boring ways: a CSS ordering difference, an environment variable that no longer exists, a dependency that assumed CommonJS. The safest approach is incremental and reversible.

From webpack to Vite

For a Vue, Svelte, or plain React app, the steps are conventional. Install Vite and its framework plugin, create a vite.config.ts, make index.html the entry point (Vite treats it that way), replace webpack-specific features such as require.context and process.env with Vite's import.meta.glob and import.meta.env, then swap loaders for equivalent plugins. Budget time for environment variables, aliases, and any code that depends on webpack magic comments. Run both builds in CI for a while and compare bundle sizes before deleting the old config.

From webpack to Rspack

If the webpack configuration is large, try Rspack first. Because it targets webpack's API, the change can be as small as swapping the compiler and fixing the handful of plugins that do not have equivalents. Check the Rspack plugin compatibility list against your actual plugin list, not the top-50 statistic.

From Create React App

The React team deprecated Create React App on February 14, 2025, explaining that it had no active maintainers and did not solve routing, data fetching, or code splitting. For new apps the team recommends a framework: Next.js, React Router, or Expo. If you have unusual constraints, it points to Vite, Parcel, or Rsbuild, and publishes migration guides for each. Existing CRA apps continue in maintenance mode with a deprecation warning on new installs.

From Node to Bun

Moving the runtime is a bigger decision than moving the bundler. Start with a non-critical service or a script, run the full test suite under Bun, and check native dependencies, which are the likeliest source of surprises. Using Bun only as a package manager or bundler while keeping Node as the runtime is a lower-risk first step. For TypeScript fundamentals that apply whichever runtime you pick, see our TypeScript guide.

Library authoring: not the same problem

Publishing an npm package is a different job from shipping an app. You want multiple output formats (ESM and CommonJS), type declarations, and little or no bundling of your dependencies.

The older recommendation was tsup. Its repository now carries the notice: "This project is not actively maintained anymore. Please consider using tsdown instead." The tsdown project is described as an official Rolldown project, inspired by tsup's developer experience and many of its command-line options. It produces ESM, CJS, IIFE, and UMD output, generates .d.ts files automatically, and supports Rolldown and most Rollup plugins. Plain Rollup remains a sound choice for libraries, and tsdown's guide says it is positioned to become the foundation for Rolldown Vite's library mode.

For apps, none of this matters. For anything you publish, check the maintenance status of your bundler before you depend on it for years.

Common mistakes

Choosing by benchmark headline. A tool that is ten times faster on someone else's benchmark may save you nothing if your slow step is type checking or an image pipeline.

Over-configuring. Modern tools have good defaults, and configuration is the top pain point in the State of JavaScript data. Every custom option is a future migration chore.

Skipping CI in the comparison. A faster dev server does not help if the pipeline downloads dependencies and rebuilds without a cache on every pull request.

Mixing tools without a reason. Using one bundler for development and another for production invites bugs that appear only after deployment. Vite 8 moving to a single bundler removed one such gap by design.

Migrating production in one step. Compare outputs, run both pipelines in parallel for a while, and keep a rollback path.

Ignoring the runtime floor. Vite 8 needs Node.js 20.19+ or 22.12+, and Next.js 16 needs Node.js 20.9+. A build tool upgrade can quietly become a Node upgrade across every CI image.

What to pick if you are...

A solo developer starting a project. Use the build tool your framework recommends. If you are starting without a framework, use Vite. You will find the most tutorials, the largest plugin pool, and the least configuration. For a broader learning sequence, see our web development learning path.

On a team with a large webpack app. Do not rewrite for fashion. Measure where the time goes first. If the build is the bottleneck, trial Rspack on a branch. If the app is a React app with routing needs, evaluate a framework migration separately from the bundler question.

Building a Next.js product. You are already on Turbopack. Your decision is whether any custom webpack plugin forces you onto --webpack, and how long you can afford to stay there.

Publishing a library. Look at tsdown or Rollup, and avoid tools flagged as unmaintained.

Building back-end tools and scripts. Evaluate Bun as a runtime first. The bundler is a bonus, not the reason.

Choosing a framework for the first time. The build tool is a downstream detail. The comparison in React vs Vue vs Svelte matters more than anything on this page.

FAQ

Q: Is Vite faster than Turbopack? A: They are not directly comparable. Vite is a general build tool, and Turbopack runs inside Next.js only. Vite's development speed comes from not bundling during development, while Turbopack bundles lazily and caches at function level. Published claims come from each project's own benchmarks, so measure on your code.

Q: Is webpack dead? A: No. It was still the most-used build tool in the State of JavaScript 2025 survey, and version 5.112 shipped in October 2026. Its satisfaction scores are far lower than Vite's, and its 2026 roadmap focuses on adding conveniences other tools already offer, such as native CSS Modules and TypeScript support.

Q: Should I migrate from webpack to Vite? A: Not automatically. Migrate when build or HMR time measurably hurts productivity, or when you are replatforming anyway. For large webpack codebases, trying Rspack first is often cheaper because it follows webpack's API.

Q: Is Bun production-ready as a bundler? A: Bun 1.0 was declared stable in September 2023, and the project kept shipping releases afterward, including Bun 1.3 in October 2025. For new projects with simple dependencies it is a reasonable choice. For established Node apps with native modules, test thoroughly and migrate one service at a time.

Q: What replaced Create React App? A: The React team recommends a framework such as Next.js, React Router, or Expo for new apps. For custom setups it points to Vite, Parcel, or Rsbuild.

Q: What should I use to publish an npm library? A: Consider tsdown, which is built on Rolldown and inspired by tsup, or plain Rollup. tsup's repository says it is no longer actively maintained.

Q: What is Rolldown, and do I need to install it? A: Rolldown is a Rust bundler from VoidZero with a Rollup-compatible API. If you use Vite 8 you already use it. You install it directly only if you want its API for your own tooling.

The takeaway

The most useful fact about build tools in 2026 is how much of the choice has been made for you. Frameworks bundle their own, Vite has become the sensible default for everything else, and the old default, webpack, is a mature tool whose strengths are compatibility and flexibility rather than speed. The Rust rewrites (Rolldown, Rspack, Turbopack) are converging on the same promise from different directions: keep the developer experience, remove the wait.

That convergence makes the decision lower-stakes than the headlines suggest. Pick the tool your framework expects, measure your own builds before believing anyone's multiplier, and revisit the question when a real constraint appears, such as a slow CI pipeline or a plugin that no longer works. The tools will keep changing. Your measurements will not go out of date as fast as anyone's benchmark chart.

Sources

• Vite 8 announcement (March 12, 2026), Vite team
• Why Vite, Vite documentation
• Vite (software), Wikipedia, for the April 20, 2020 first release
• Next.js 16 release post (October 21, 2025), Vercel
• Turbopack documentation, Next.js, last updated October 6, 2026
• webpack blog and Roadmap 2026, webpack team
• Module Federation, webpack documentation
• State of JavaScript 2025: build tools and InfoQ's summary
• Bun blog, Bun is joining Anthropic, and Bun bundler docs
• Rspack introduction and esbuild
• Sunsetting Create React App, React team, February 14, 2025
• tsdown guide and tsup repository
• Parcel