★ 82,117TypeScriptMITupdated Jul 2026
best for building a modern app today — fast dev server, real HMR, sane defaults out of the box
Vite is what most new frontend projects should reach for first. The dev server serves native ES modules instead of bundling everything upfront, so cold start stays fast no matter how big the app gets, and HMR is granular enough that you can forget it's there.
The catch is that dev and production are two different machines under the hood — unbundled ESM in the editor, a Rolldown-bundled output in prod — so a class of bugs only shows up after you build, and you can't always reproduce them locally. SSR is still catching up too; the module runner API keeps shifting under framework authors, so anything beyond a standard meta-framework setup can hit edge cases.
Compared to Rspack or webpack, Vite trades config control for defaults that mostly just work — until your project grows and you end up writing a vite.config that quietly reinvents half of what webpack's plugins already solved.
Our full take →GitHub ↗
★ 65,971JavaScriptMITupdated Oct 2026
best for deeply custom or legacy builds where config control matters more than raw speed
Webpack is still the right call when you need build behavior no other tool gives you out of the box — custom loader chains, non-standard module resolution, a chunk graph tuned by hand. The loader and plugin architecture is genuinely battle-tested, and there's a loader for almost anything you'd want to do to a file.
What it costs you is time. Config for anything past the defaults is verbose, and the learning curve is real — splitChunks and resolution edge cases alone can eat a day. Rebuilds still lag behind Vite, esbuild, and Rspack even with caching on, and the README spends more space on sponsor logos than explaining any of this, so you end up in external docs immediately.
If what you actually want is webpack's config model without webpack's speed, Rspack gets you most of the way there without a rewrite. Pick plain webpack only when you specifically need a plugin or resolution behavior Rspack hasn't matched yet.
Our full take →GitHub ↗
★ 39,950GoMITupdated Jun 2026
best for raw bundling speed as a building block inside your own toolchain
esbuild is the thing other tools use to go fast — Vite reaches for it to pre-bundle dependencies, and tsup wraps it entirely for library builds. On its own it's a genuinely fast single-pass bundler written in Go, and if you're building your own toolchain rather than adopting someone else's, it's the obvious primitive to start from.
The gaps show up once you try to use it as a complete build tool rather than a building block. It strips TypeScript types without checking them, so you need a separate tsc pass just to catch type errors in CI. There's no HMR, only live reload, so frameworks that need real hot module replacement leave you implementing it yourself. And the plugin ecosystem is thin — past basic asset handling, you're usually writing the plugin, not finding one.
Bun gives you esbuild-level bundling speed plus a runtime, package manager, and test runner around it. esbuild gives you none of that — just the fast part, which is exactly the point if that's all you need.
Our full take →GitHub ↗
★ 12,950RustMITupdated Oct 2026
best for teams with an existing webpack config who want it faster without a rewrite
Rspack exists for one specific situation: you have a real webpack config and plugin stack, and you want it faster without rewriting any of it. The engineering behind it is serious — proper chunk graph, module federation, incremental builds — backed by ByteDance with benchmarking infrastructure that actually tracks regressions instead of just claiming speed.
Webpack compatibility is the pitch, but it's advertised further than it's guaranteed. Plugins that lean on deep internal webpack APIs or uncommon hooks can still break, and you won't know until you try your exact setup. It also inherits webpack's config complexity rather than solving it — you're not escaping the conceptual baggage, just making it run faster. And because the core is Rust, fewer people on your team can actually dig in and fix something themselves compared to a pure-JS tool.
If you're starting fresh rather than migrating, Vite is the simpler bet. Rspack earns its keep specifically for teams already stuck on webpack who can't justify a rewrite.
Our full take →GitHub ↗
★ 44,007JavaScriptMITupdated Oct 2026
best for a build tool that just works with zero configuration
Parcel's whole pitch is that you don't configure it — point it at an HTML or JS entry file and it figures out the rest, dev server, HMR, and production optimization included. For straightforward JS/TS/CSS/HTML projects that's genuinely true, and the resolver and HTML pipeline are written in Rust rather than bolted-on JS, so it's not zero-config at the cost of being slow.
The zero-config story stops being true the moment you need anything nonstandard. Then you're in .parcelrc and an underdocumented plugin API, with none of the depth of guides webpack's ecosystem has built up over a decade. The codebase mixes Flow types, Rust crates, and JS across many packages, which makes debugging a build issue yourself harder than it should be, and the v1-to-v2 migration was rough enough that it's still a live memory for people who lived through it.
Vite gets you similar zero-config defaults with a much larger plugin ecosystem to fall back on when you outgrow them. Parcel is worth it mainly when you genuinely want to never open a config file, and you're willing to accept the wall you'll eventually hit.
Our full take →GitHub ↗
★ 26,304JavaScriptNOASSERTIONupdated Oct 2026
best for bundling a library down to clean ES modules
Rollup is the right tool once you're shipping a library, not an app. Its tree-shaking is still better than most bundlers' dead-code elimination because it's based on real static analysis of ES modules, and it's also what's running under the hood of Vite's own production build — so you're already using it, whether you know it or not.
What it doesn't give you is a dev server or HMR, which means for actual application development you end up pulled into Vite anyway — standalone Rollup is really a library-bundling tool at this point, not a general build tool. Plugin and transform ordering are long-standing sources of confusion, and CommonJS interop still needs a separate plugin with its own edge cases around default exports.
If your library is TypeScript and you don't want to write a Rollup config at all, tsup gets you most of the same output with far less setup — at the cost of being built on a deprecated foundation, which Rollup isn't.
Our full take →GitHub ↗
★ 11,275TypeScriptMITupdated Jun 2026
best for the smallest possible setup for shipping a TypeScript library
tsup is the fastest path to a published TypeScript package — point it at your entry file and get CJS and ESM output with working interop shims, in under ten lines of config. It's built on esbuild, so rebuilds are close to instant compared to a Rollup-based setup, and the automatic dual-output handling solved a real headache for library authors before the exports field was well understood.
The problem is sitting right in the README: the maintainer has deprecated it in favor of tsdown, so adopting tsup now means planning a migration before you've even shipped your first version. CSS support is still marked experimental after years, which is usually a sign a project ran out of steam before finishing. Declaration file generation leans on a separate tsc or api-extractor pass, so anything with complex generics or module augmentation can come out with a broken .d.ts that esbuild has no way to fix.
Rollup is more setup, but it's actively maintained and doesn't come with a deprecation notice attached. Only reach for tsup if you want the smallest possible config and you're fine migrating off it later.
Our full take →GitHub ↗
★ 93,131RustNOASSERTIONupdated Jun 2026
best for teams willing to adopt bun's runtime and get bundling built in for free
Bun is the pick if you're willing to adopt the runtime, not just the bundler — you get package installs that finish in seconds instead of thirty, a test runner, and TypeScript execution with no build step, all in one binary. The bundler itself is fast for the same reason esbuild is: it's not reimplementing JS tooling in JS.
The 'drop-in Node replacement' framing is aspirational once your codebase has native addons or leans on module-system edge cases — it mostly works until it doesn't, and you find out which on your own project. It's also maintained by one company with a small core team, which matters if you're putting it under anything you'd call critical infrastructure, and Windows support still trails Linux and macOS on I/O. As a bundler specifically, it's less configurable than esbuild or webpack — fine for a standard app, but you'll hit a wall fast if you need real chunk splitting or module federation.
Reach for Bun when you want to replace your whole toolchain, not just the bundler piece. If you only need the bundler, esbuild gives you the same speed without asking you to adopt a new runtime.
Our full take →GitHub ↗
// questions people ask
Before you choose
Should I use Vite or webpack for a new project in 2026?
Vite, unless you have a specific reason not to — faster dev server, simpler config, and most frameworks assume it by default now. Reach for webpack only if you need a specific loader or resolution behavior its plugin ecosystem still does better.
Is Rspack a safe replacement for webpack?
For most projects, yes — it mirrors webpack's API closely enough that teams migrate without rewriting their config. The exception is plugins that rely on deep internal webpack APIs or uncommon hooks, which can break in ways you won't find until you test your own setup.
Should I bundle a library with Rollup or tsup?
tsup if you want the smallest config and don't mind migrating later — it's built on esbuild and the maintainer has already deprecated it in favor of tsdown. Rollup if you want something actively maintained with better tree-shaking, at the cost of more setup.
Does Bun replace the need for a separate bundler?
Only if you're also adopting Bun as your runtime and package manager — its bundler alone is less configurable than esbuild or webpack for complex output shapes. If you just want a fast standalone bundler without changing your runtime, esbuild or Vite are the better fit.
None of these is wrong, exactly — they're built for different moments in a project's life, and the honest answer is usually 'depends what you're already running.' If you want picks like these without going looking for them, the weekly email does that part for you.