Turbopack - Finally, a bundler that doesn't suck

Look, I'm tired of webpack taking 5 minutes to build our damn app. Tobias Koppers made webpack, got sick of it being slow as hell, and built Turbopack in Rust instead. Smart move.

The Build Time Hell Problem

We've all been there - you change one line of CSS and webpack takes 30 seconds to hot reload. Our team wasted probably 2 hours a day waiting for builds on a 200k line React app. Ask any developer - build times are everyone's #1 complaint.

Turbopack actually fixes this with incremental computation - it only rebuilds what changed and caches everything at the function level. No more rebuilding the entire app when you fix a typo.

The unified architecture handles client, server, and edge builds in one go instead of managing three separate webpack configs that inevitably break each other. No more debugging webpack config conflicts between development and production modes.

Performance Numbers That Don't Completely Lie

Next.js added production builds to beta recently. The marketing claims 700x faster HMR only applies with 30k+ modules and perfect conditions. Real apps see 2-5x improvements, which is still worth it:

• ~2x faster builds on my 4-core laptop (4 min → 2 min, not instant but better)
• 3x faster on CI with 8-core GitHub runners, saves us money
• 10x faster HMR - went from 2-3 seconds to 200ms, actually usable now
• Cold starts don't suck - 45 seconds to 12 seconds on our massive monorepo setup

Your mileage will vary based on project size, webpack config, and whether you're stuck on Windows/WSL2.

Production Reality Check

They're running it on vercel.com, v0.app, and nextjs.org in actual production. That's real validation, not just toy demos. Bundle sizes are comparable or smaller than webpack in most cases.

But it's still beta for production builds - we're using it on staging, not betting the company on it yet. Check the compatibility docs before you migrate your critical stuff. The official Turbopack roadmap shows what's coming next if you want to track progress.

The Rust Gamble

Half the JavaScript ecosystem is moving to Rust now - SWC, Biome, Lightning CSS. Turbopack joins the club because JavaScript tooling performance hits a wall at scale. Pro tip: if you see 'rewritten in Rust' in 2025, there's probably a good reason.

Rust gives them memory safety without garbage collection overhead and actual parallelization instead of the single-threaded JavaScript event loop bullshit. The tradeoff? Fewer people can contribute fixes when things break, and debugging Rust panics is not fun. But the Rust book explains why panics happen if you're brave enough to dig in.

Worth it though - my builds are finally fast enough that I don't go get coffee while waiting. If you're curious about the technical details, check out the Turbopack architecture deep dive.

But performance claims are just marketing until you compare them to real alternatives. Time to see how it actually compares to other bundlers.

The marketing says "just add --turbopack and it works!" Reality is messier. Production builds are still in beta over a year after launch. Don't migrate your production app on a Friday.

The "Simple" Setup (That Usually Works)

For basic Next.js apps, yeah it's pretty easy:

{
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build --turbopack", 
    "start": "next start"
  }
}

If you're lucky and have zero custom webpack config, this might actually work first try. Most apps are not this simple.

What Actually Works Without Breaking

Basic stuff that works fine:

• TypeScript and JSX - yeah, the basic stuff works fine
• CSS modules and Sass - if you're into that
• Regular imports and static assets - not rocket science
• Hot module replacement that doesn't take forever

Less basic stuff:

• PostCSS configuration gets picked up automatically
• Path aliases from your tsconfig.json work
• Tree shaking works but isn't as aggressive as webpack yet

Where It All Goes Wrong (Migration Reality)

"Most applications work immediately" is bullshit marketing speak. Here's what actually breaks:

Things That Will Ruin Your Day:

• Custom webpack plugins: Not supported, period. Hope you weren't using Bundle Analyzer or anything important
• Complex SVG handling: Our @svgr/webpack setup took 3 hours to migrate and still doesn't work exactly right. You'll see Error: Cannot resolve module for SVG imports and want to throw your laptop
• Weird CSS-in-JS libraries: Some styled-components patterns break mysteriously with ReferenceError: styled is not defined at runtime. Took down our staging for 2 hours figuring that shit out
• Yarn PnP or pnpm with hoisting issues: Just use npm and save yourself the pain. pnpm will give you ENOENT: no such file or directory errors that make no sense

The "Simple" Config That Isn't Simple:

When the basic setup fails (and it will), you'll need this mess in next.config.js:

module.exports = {
  turbopack: {
    rules: {
      // This took forever to get working
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
      // Custom fonts break without this
      '*.woff2': {
        loaders: ['file-loader'],
        as: '*.woff2',
      },
    },
    resolveAlias: {
      // Because your import paths are probably fucked
      '@components': './src/components',
      '@utils': './src/utils',
    },
    resolveExtensions: ['.mdx', '.tsx', '.ts', '.jsx', '.js', '.json'],
  },
}

Debugging When It Breaks:

Enable tracing because the error messages are useless as always:

NEXT_TURBOPACK_TRACING=1 next dev --turbopack

This dumps a .next/trace-turbopack file you can attach to GitHub issues when asking for help. Pro tip: if you get thread 'main' panicked at 'already borrowed: BorrowMutError', just delete node_modules and .next and try again. Half the problems go away with the nuclear option.

Time Investment Reality:

• Basic app: 10 minutes if you're lucky and have zero custom config, otherwise plan for an afternoon of debugging
• App with custom webpack config: Plan a weekend. I'm not joking - check the compatibility matrix or prepare to debug webpack plugin hell for 8 hours
• Complex monorepo setup: Maybe just stick with webpack for now, I learned this the hard way

Test thoroughly on staging before touching production. The beta label exists for a reason - check current known issues first.

After going through this migration hell multiple times, I keep getting the same questions from colleagues. Here's what I wish someone had told me.

Everyone's rewriting JavaScript tools in Rust now. Sometimes it's just hype (looking at you, Rome/Biome), sometimes it actually matters. Turbopack might be in the "actually matters" category, but let's be realistic about the timeline.

Where We Are Now (September 2025)

Production builds went to beta over a year ago. Still in beta. That's... not super encouraging, but "beta" means "don't bet your company on it yet." The dev team is working on:

Persistent Caching: Right now Turbopack only caches in memory, so every cold start rebuilds everything. They're adding disk-based persistence for instant restarts. This will be huge when it works.

Memory Usage: Function-level caching sounds great until your laptop runs out of RAM. They're improving cache eviction so it doesn't eat 8GB on large projects.

Missing Optimizations: Webpack's Inner Graph Optimization and advanced tree shaking aren't implemented yet. Bundle sizes are comparable but not better than webpack's best output.

The Great Rust Rewrite Trend

The JavaScript ecosystem is having its Rust moment. Some tools deliver on the promises, others are just hype:

• SWC (Speedy Web Compiler) - actually faster than Babel, widely adopted
• Rome/Biome (biomejs.dev) - overpromised, underdelivered, forked and rebranded
• esbuild (Go, not Rust) - proved native tooling works, inspired everything else
• Rolldown (Rust Rollup) - in development, might matter if they ship
• Lightning CSS (lightningcss.dev) - fast PostCSS replacement, used by Turbopack

Pattern: Native tooling helps, but shipping working software matters more than the language choice.

Enterprise Reality Check

Vercel using Turbopack on their own sites is genuine validation, not marketing fluff. But "enterprise adoption" means banks and insurance companies, not just Vercel's Next.js sites.

Real enterprise benefits:

• Faster CI/CD: 2-3x faster builds save money on GitHub Actions minutes
• Developer productivity: Less waiting around, more actual coding
• Future scaling: Won't hit performance walls as fast as webpack does

But enterprises move slowly. Most will wait for stable releases and proven track records before migrating critical systems.

Migration Strategy Reality

The "gradual adoption" story is mostly true. You can try dev mode immediately, production builds when ready. The webpack compatibility layer handles basic configs.

But "gradual" becomes "painful" with custom webpack plugins, complex CSS setups, or monorepo configurations. Plan for weeks of migration time, not hours.

What Actually Happens Next

Turbopack becomes webpack's successor if they deliver on:

• Stable production builds (maybe Q1 2026? who knows)
• Standalone usage outside Next.js (timeline unknown, could be never)
• Plugin ecosystem that doesn't suck (years away, if ever)

Until then, it's a Next.js-specific performance boost. That's still valuable, but not the universal webpack replacement yet.

The real win? Proof that rewriting JavaScript tools in Rust actually works. That trend continues regardless of whether Turbopack specifically wins.

Bottom line: If you're on Next.js and tired of slow builds, try Turbopack today for development. It works, it's fast, and worst case you flip it off with one flag. For production, wait another 6 months - the beta warning exists for a reason, and I've seen too many "it worked in dev" disasters to count.

Don't expect it to solve every webpack problem overnight though. Some pain is inherent to complex build tooling, no matter what language it's written in. But at least your builds won't take fucking forever anymore.