Webpack vs Vite vs Turbopack

The JavaScript bundler wars are not about which tool is "best" — they're about which tool matches your constraints. Webpack dominates large enterprise codebases. Vite owns the modern DX space. Turbopack is betting on incremental computation. Knowing the architectural differences and trade-offs is what separates a senior engineer from someone who just follows trends.

Webpack 5: The Incumbent

Webpack 5 (released 2020) brought major improvements that keep it competitive:

Key Webpack 5 Features

Module Federation: Share live modules between independently deployed applications at runtime.

// app-shell/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
 
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        dashboard: 'dashboard@https://dashboard.example.com/remoteEntry.js',
        settings: 'settings@https://settings.example.com/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};

// dashboard/webpack.config.js
new ModuleFederationPlugin({
  name: 'dashboard',
  filename: 'remoteEntry.js',
  exposes: {
    './DashboardApp': './src/App',
    './widgets': './src/widgets',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
  },
});

Module Federation is webpack's moat — no other bundler has a production-proven equivalent at this scale.

Asset Modules: Built-in handling for images, fonts, and files without external loaders.

Persistent Caching: Filesystem-level caching that cuts rebuild times by 80-90%.

Improved Tree Shaking: Better support for exports field, nested tree shaking, and inner graph analysis.

Webpack's Strengths

• Massive ecosystem (thousands of loaders and plugins)
• Battle-tested in production at every scale
• Module Federation for micro-frontends
• Extremely configurable — can handle any use case
• Mature tooling for analysis, profiling, debugging

Webpack's Weaknesses

• Slow cold starts (seconds to minutes for large projects)
• Complex configuration (webpack.config.js is an art form)
• JavaScript-based architecture hits V8 performance limits
• HMR can be slow in very large codebases

Vite: The Modern Standard

Vite takes a fundamentally different approach: don't bundle during development.

Vite Architecture

Traditional Bundler (webpack):
  Source files → Bundle everything → Serve bundle → Browser
 
Vite Dev Server:
  Source files → Serve individual ES modules → Browser imports on demand
              ↕
         esbuild (pre-bundles dependencies only)

Dev Server Architecture:
┌─────────────────────────────────────────┐
│ Browser (native ESM)                    │
│  import App from '/src/App.tsx'         │
│  → HTTP request to Vite dev server      │
└────────────────┬────────────────────────┘
                 │
┌────────────────▼────────────────────────┐
│ Vite Dev Server                         │
│  1. Transform requested file on demand  │
│  2. Apply plugins (esbuild/SWC)         │
│  3. Return ES module to browser         │
└────────────────┬────────────────────────┘
                 │
┌────────────────▼────────────────────────┐
│ Pre-bundled Dependencies (esbuild)      │
│  node_modules/ → .vite/deps/            │
│  react.js, lodash-es.js (CJS → ESM)    │
└─────────────────────────────────────────┘

Why Vite is Fast

1. No bundling in dev: Files are served as native ES modules. The browser does the module resolution.
2. On-demand compilation: Only the files the browser requests are transformed — no upfront work.
3. esbuild for dependency pre-bundling: Converts CJS to ESM and bundles node_modules into single files (10-100x faster than JavaScript-based tools).
4. Native ESM HMR: Updates are surgical — only the changed module and its immediate importers are invalidated.

Vite Configuration

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
 
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': '/src',
    },
  },
  server: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
      },
    },
  },
  build: {
    target: 'es2020',
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
        },
      },
    },
  },
});

Vite's Production Build

Vite uses Rollup for production builds, not esbuild. Why? Rollup produces better optimized output with superior tree shaking, code splitting, and a mature plugin ecosystem for production needs.

Dev:   esbuild (fast transforms) + native ESM (no bundling)
Prod:  Rollup (optimized bundling) + esbuild (minification)

This dual architecture is both a strength (best tool for each job) and a weakness (dev/prod divergence can cause subtle bugs).

Vite's Limitations

• Dev/prod divergence: esbuild in dev, Rollup in prod — rare but real behavioral differences
• No Module Federation: No production-equivalent feature (though Module Federation for Vite is in development)
• Large dependency pre-bundling: Initial node_modules pre-bundling can be slow for massive dependency trees
• Plugin ecosystem: Smaller than webpack's, though growing rapidly
• SSR: Supported but less mature than Next.js/webpack SSR

Turbopack: The Next Generation

Turbopack (by Vercel, from the webpack creator) is a Rust-based bundler built on incremental computation.

Architecture

Turbopack's Key Innovation: Function-Level Caching
 
Traditional bundler:
  file changes → recompute affected modules → rebundle
 
Turbopack:
  file changes → recompute ONLY the specific functions
  whose inputs changed → surgical update
 
┌─────────────────────────────────────────┐
│ Turbo Engine (Rust)                     │
│  ├── Incremental computation graph      │
│  ├── Function-level memoization         │
│  ├── Parallel execution                 │
│  └── Persistent caching                 │
└─────────────────────────────────────────┘

Why Turbopack is Fast

1. Rust: No garbage collection pauses, predictable performance, native parallelism
2. Incremental computation: Every function in the build pipeline is memoized — if inputs haven't changed, the result is reused
3. Function-level caching: More granular than file-level — a function that parses imports can be cached even if the file's function bodies change
4. Native parallelism: Rust's ownership model enables safe concurrent processing

Current Status

Turbopack is integrated into Next.js (next dev --turbopack). It's focused on development speed first, with production builds coming later.

# Next.js with Turbopack
next dev --turbopack
 
# Performance comparison (Next.js app, 5000 modules)
# webpack: 12s cold start, 500ms HMR
# Turbopack: 2s cold start, 50ms HMR

esbuild: The Speed Demon

esbuild is written in Go and focuses purely on speed:

# 1000x faster than webpack for pure bundling
esbuild src/app.tsx --bundle --outfile=dist/app.js --minify

esbuild Limitations

• No HMR
• Limited code splitting (improving)
• No module.hot API
• Limited plugin API compared to webpack
• Not designed as a full application bundler

esbuild excels as a component inside other tools (Vite uses it for pre-bundling and minification) rather than a standalone build system.

Rollup: The Library Bundler

Rollup pioneered ES module bundling and tree shaking. It's the production bundler behind Vite and the go-to for library authors:

// rollup.config.js
export default {
  input: 'src/index.ts',
  output: [
    { file: 'dist/index.cjs.js', format: 'cjs' },
    { file: 'dist/index.esm.js', format: 'es' },
  ],
  external: ['react', 'react-dom'],
  plugins: [typescript(), resolve(), commonjs()],
};

Rollup's advantage: Produces cleaner output than webpack because it was designed for ES modules from day one. Its tree shaking is more aggressive.

Rollup's limitation: Not optimized for applications with thousands of modules and complex dev server needs — that's why Vite wraps it rather than using it directly for dev.

Rspack: The Webpack-Compatible Rust Bundler

Rspack (by ByteDance) takes a different approach from Turbopack — instead of reinventing the API, it implements the webpack API in Rust:

// rspack.config.js — looks just like webpack!
module.exports = {
  entry: './src/index.js',
  module: {
    rules: [
      { test: /\.tsx?$/, use: 'builtin:swc-loader' },
    ],
  },
  plugins: [new rspack.HtmlRspackPlugin()],
};

Key advantage: Drop-in webpack replacement for many projects. Most webpack loaders and plugins work with minimal changes.

Performance: 5-10x faster than webpack while maintaining compatibility.

Comprehensive Comparison

Migration Path: Webpack to Vite

Step-by-Step Migration

1. Audit webpack config
   ├── List all loaders and their Vite equivalents
   ├── List all plugins and their Vite equivalents
   └── Identify webpack-specific features (Module Federation, etc.)
 
2. Handle blockers
   ├── CommonJS-only dependencies → may need pre-bundling config
   ├── webpack-specific imports (require.context) → import.meta.glob
   ├── DefinePlugin → define in vite.config
   └── Module Federation → may block migration
 
3. Create vite.config.ts
   ├── Move resolve.alias → resolve.alias
   ├── Move proxy → server.proxy
   └── Add framework plugin (@vitejs/plugin-react)
 
4. Update entry point
   └── index.html becomes the entry (not JS file)
 
5. Replace webpack-specific APIs
   ├── require.context → import.meta.glob
   ├── module.hot → import.meta.hot
   └── process.env → import.meta.env

Common API Translations

// webpack: require.context
const modules = require.context('./modules', true, /\.ts$/);
 
// vite: import.meta.glob
const modules = import.meta.glob('./modules/**/*.ts');
// Returns: { './modules/foo.ts': () => import('./modules/foo.ts') }
 
// webpack: process.env
process.env.API_URL
 
// vite: import.meta.env (must be prefixed with VITE_)
import.meta.env.VITE_API_URL
 
// webpack: module.hot
if (module.hot) module.hot.accept();
 
// vite: import.meta.hot
if (import.meta.hot) import.meta.hot.accept();

Decision Matrix

When to Use Webpack

• Large enterprise applications with complex requirements
• Module Federation / micro-frontend architectures
• Highly customized build pipelines with many loaders/plugins
• Legacy codebases where migration cost exceeds benefit
• Need for the most extensive plugin ecosystem

When to Use Vite

• New greenfield projects (any framework)
• Developer experience is a priority
• Standard SPA or SSR applications
• Team wants minimal configuration
• Library development (via Vite's library mode)

When to Use Turbopack

• Next.js projects (currently the only supported framework)
• Massive codebases where even Vite's dev server is slow
• Teams willing to adopt bleeding-edge tooling

When to Use Rspack

• Existing webpack projects that need better performance
• Teams that want webpack compatibility without rewriting configs
• Projects blocked from Vite migration by webpack-specific features

When to Use Rollup

• Library/package development
• Need the cleanest possible ESM output
• Vite production builds (it's already using Rollup)

When to Use esbuild

• As a transpiler/minifier inside other tools
• Simple bundling tasks with no HMR requirement
• CI pipelines where raw speed matters most

The Convergence Trend

The ecosystem is converging:

2020:  Webpack does everything (slowly)
2022:  Vite for dev, Rollup for prod, esbuild for speed
2024:  Turbopack for Next.js, Rspack for webpack compat
2025+: Rolldown (Rust Rollup) will unify Vite's dev/prod
       Turbopack expands beyond Next.js
       Rspack matures as the webpack successor

The future is Rust-based tooling with JavaScript-level plugin APIs. The winner isn't determined yet, but the direction is clear: native-speed builds with web-ecosystem compatibility.

Interview Power Moves

• "Vite's dev server doesn't bundle — it serves native ES modules and only transforms what the browser requests. That's why cold starts are instant." Demonstrates understanding of the architectural difference, not just "Vite is faster."
• "Turbopack's innovation is function-level memoization, not just 'being written in Rust.' Any function whose inputs haven't changed returns a cached result." Shows you understand the incremental computation model.
• "Module Federation is webpack's moat — it's the only production-proven way to share live modules between independently deployed apps at runtime." Explains why enterprises can't just switch to Vite.
• "Vite uses esbuild for dev transforms and Rollup for prod builds. This dual architecture is pragmatic but can cause subtle dev/prod differences." Balanced perspective, acknowledges trade-offs.
• "Rspack implements the webpack API in Rust — it's a migration path, not a competitor. You keep your webpack config and get 5-10x faster builds." Shows you think about migration pragmatically.
• "I'd evaluate based on three axes: does the team have existing webpack investment, do they need Module Federation, and how large is the codebase. Those three factors determine the right bundler." Architect-level framing of the decision.