Parcel, Rspack, Turbopack — when they fit

🎯 Chapter Goal — After this chapter you can identify the narrow situations where Parcel, Rspack, or Turbopack is a better fit than Vite, and avoid being talked into them when Vite is the right answer.

🧭 Prerequisites — Ch 16 (landscape) and Ch 17 (Vite deep dive).

---

🔹 20.1 Parcel — when zero-config wins

npm install -D parcel
parcel index.html

That’s it. Parcel detects the entry, transpiles TS, JSX, Sass, applies PostCSS, runs a dev server, hot-reloads.

Parcel wins when:

• Prototype, hackathon, course project.
• A landing page that ships next week and will never grow.
• Onboarding new developers to “make this run” with zero ceremony.
• A multi-page static site with mostly HTML.

Parcel loses when:

• You need custom Rollup/Vite plugins (Parcel has its own plugin system; ports are slow).
• You need a strict module-graph contract for tree-shaking.
• You’re in a monorepo with shared tooling — Parcel’s caching doesn’t compose with Turborepo as cleanly as Vite’s.
• Your team values the Vite mental model and pre-existing knowledge.

Honest assessment: in 2026, Parcel is shrinking as a SPA choice. The “zero config” advantage is smaller now that Vite ships sensible defaults too. Use Parcel deliberately for what it’s best at — not as a Vite alternative for general SPA work.

---

🔹 20.2 Rspack — when Webpack 5 compatibility is the constraint

https://rspack.dev — Rust-written, Webpack-API-compatible. ByteDance built it for their internal Webpack 5 fleet.

npm install -D @rspack/cli @rspack/core
# port your webpack.config.js → rspack.config.js (often a renamed file works)

Rspack wins when:

• You have a non-trivial Webpack 5 config you can’t (or won’t) port to Vite’s Rollup model.
• You have custom Webpack loaders or plugins critical to your build.
• You need Module Federation under Webpack semantics (Ch 26 — @module-federation/enhanced is the Rspack path).
• Your team has deep Webpack expertise; learning Rspack is a small delta vs learning Vite’s full model.

Rspack loses when:

• You’re starting from scratch — Vite is simpler.
• Your Webpack config is small — porting to Vite is days, not weeks.
• You need Vite’s plugin ecosystem (which is larger).

The migration math: Rspack from Webpack 5 is usually a 1-week project; Vite from Webpack 5 is usually 2–4 weeks. Pick by what your config looks like.

---

🔹 20.3 Turbopack — when Next.js is the runtime

https://turbo.build/pack — Vercel’s Rust-written Webpack replacement, primarily for Next.js dev mode.

In 2026, Turbopack is transparent in Next.js — you don’t choose it explicitly; it powers next dev and (increasingly) next build. Outside Next.js, Turbopack as a standalone tool is not yet mainstream.

Turbopack wins when: you’re on Next.js. It just happens.

Turbopack loses when: you’re not on Next.js. There’s no compelling reason to wire it up standalone today.

If you’re a Next user and confused about whether Turbopack is active, check next.config.js — experimental.turbo or the framework default. The team’s plan as of 2026 is Turbopack-by-default for both dev and prod by the end of the year.

---

🔹 20.4 The “should I switch from Vite?” honest take

You’re on Vite. You read a benchmark showing Rspack is 30 % faster. Should you switch?

Almost certainly no. Three honest reasons:

1. 30 % of a 12 s build is 4 s saved. Your team’s daily wins from Vite’s plugin ecosystem dwarf 4 s/build.
2. Benchmarks measure synthetic cases. Your project has plugins, CSS, type-checking, tests — most of the “build time” is not the bundler.
3. The switch costs weeks. Every plugin needs verification or replacement. Every CI step needs adjustment. Every developer needs re-onboarding.

The only honest reasons to leave Vite:

• A specific feature you need (Webpack-flavor Module Federation; Next.js framework features).
• A specific bug you’ve hit and can’t fix.
• A monorepo where one workspace’s bundler choice constrains everyone (rare).

---

🪤 Common Pitfalls

1. Switching bundlers for “speed” without measuring your actual bottleneck.
2. Parcel for a real SPA → outgrown within 6 months.
3. Rspack ported from Webpack without removing dead Webpack-only plugins.
4. Turbopack outside Next → wasted effort; tooling isn’t there.

---

✅ Recap

• Parcel for zero-config prototypes and content-heavy sites; not for production SPAs that will grow.
• Rspack as the Webpack-5 migration target when porting to Vite isn’t feasible.
• Turbopack only inside Next.js, transparently.
• Don’t switch from Vite without a concrete pain to solve.

---

🔗 Further Reading

• https://parceljs.org/ — Parcel 2.x docs.
• https://rspack.dev/ — Rspack docs (the drop-in Webpack 5 replacement).
• https://turbo.build/pack — Turbopack docs (Next.js / Vercel).
• Ch 16 (landscape), Ch 17 (Vite), Ch 21 (CRA migration).