, Vercel has published a detailed technical breakdown of Turbopack's architecture, specifically focusing on how incremental computation enables the bundler to achieve significant performance improvements over traditional approaches. This deep dive reveals the architectural decisions that allow Turbopack to scale to massive Next.js applications while maintaining fast iteration speeds.

Turbopack fundamentally rethinks how bundlers process code by implementing incremental computation at its core. Rather than rebuilding entire dependency graphs on every change, Turbopack tracks granular dependencies and recomputes only what's necessary. This isn't just about caching—it's about building a computation graph that understands the relationships between every piece of your application.

The key innovation here is the function-level memoization system. When you modify a component, Turbopack doesn't invalidate the entire module or its dependents. Instead, it tracks which specific computations depend on the changed code and recomputes only those affected paths. This approach becomes exponentially more valuable as applications grow larger.

The architecture uses a technique called "lazy computation" where work isn't performed until results are actually needed. Combined with persistent caching across development sessions, this means subsequent dev server starts can be nearly instantaneous, even for applications with hundreds of thousands of modules.

For teams working on large-scale Next.js applications, this architectural shift addresses one of the most painful aspects of modern frontend development: slow iteration cycles. When your application reaches 50,000+ modules, traditional bundlers struggle because they lack the granularity to understand what actually needs to be rebuilt.

The incremental computation model means developers can expect consistent performance regardless of application size. A change to a leaf component in a massive app should trigger the same minimal recomputation as it would in a small project. This consistency is crucial for maintaining developer productivity as codebases scale.

The persistent caching layer deserves special attention. Unlike traditional build caches that reset between sessions, Turbopack maintains a cache that survives server restarts. This means the second time you start your dev server, it can reuse computations from previous sessions. For monorepos or applications with extensive third-party dependencies, this can reduce cold start times from minutes to seconds.

Let's examine what this means in real-world scenarios. Consider a typical Next.js application with server components, client components, and API routes:

When you modify this component, Turbopack's incremental system:

1. Identifies that only chart.tsx changed

3. Updates only the affected bundles (the client bundle for this route)

4. Leaves server component bundles, API routes, and unrelated client components untouched

This granular approach extends to the dependency graph. If you modify a utility function:

Turbopack traces which modules import this function and recompiles only those modules plus their immediate consumers. Modules that import other functions from analytics.ts remain cached if those functions haven't changed.

The impact becomes dramatic in monorepo scenarios. When working on a specific package within a monorepo, changes don't trigger unnecessary recompilation of unrelated packages. The computation graph understands package boundaries and respects them during invalidation.

The incremental computation model shows its value under specific conditions. For initial builds, Turbopack still needs to process the entire application, though parallel processing helps. The real gains appear during development iterations:

- File change to HMR: Typically under 100ms for isolated component changes

- Dependency updates: Only affected modules recompile, not the entire graph

- Cold starts (second session): Leverages persistent cache for near-instant startup

- Large-scale refactors: Incremental invalidation prevents full rebuilds

These characteristics make Turbopack particularly effective for applications with:

The incremental computation system requires careful consideration of side effects. Pure transformations work perfectly with memoization, but operations with side effects need explicit handling. Turbopack tracks file system operations, environment variables, and other external inputs as part of its dependency graph.

Developers should understand that the caching layer stores computation results on disk. For teams with limited disk space or CI environments, this means configuring cache size limits and cleanup strategies:

The memory footprint of the computation graph itself also grows with application size. While Turbopack optimizes for memory efficiency, applications with hundreds of thousands of modules will see higher baseline memory usage compared to simpler bundlers.

For existing Next.js projects, enabling Turbopack requires minimal configuration changes. The incremental computation benefits apply automatically once enabled:

However, teams should verify that custom webpack configurations translate properly. Some webpack-specific optimizations may need reimplementation using Turbopack's plugin system.

The persistent cache means first-time setup requires an initial build to populate the cache. Subsequent sessions benefit immediately. For CI/CD pipelines, consider preserving the cache directory between builds to leverage incremental computation across pipeline runs.

The incremental computation architecture positions Turbopack as a foundation for future optimizations. The granular dependency tracking enables features like predictive compilation (precompiling likely-to-be-needed modules) and distributed caching across team members.

For React developers working on large-scale applications, understanding Turbopack's incremental model helps optimize code organization. Structuring code to minimize cross-module dependencies maximizes the benefits of granular invalidation. Keeping utility functions focused and components modular aligns perfectly with how Turbopack's computation graph tracks changes.

Turbopack's Zero-Work Strategy: Build Less, Ship Faster

React 19 introduces the use() hook, a powerful primitive that enables components to read resources like Promises and Context more ergonomically. For teams currently using Zustand, this new capability presents an opportunity to simplify state management patterns and reduce external dependencies. This migration path requires careful consideration of trade-offs between Zustand's mature ecosystem and React's native capabilities.

The use() hook differs from traditional hooks by allowing conditional calls and supporting Promise resolution directly within components. Unlike useState or useEffect, use() can appear inside loops and conditional statements, making it more flexible for dynamic data scenarios.

The hook integrates with Suspense boundaries, automatically triggering loading states when Promises are pending. This creates a declarative approach to async state management that eliminates much of the boilerplate typically associated with loading and error states.

Zustand provides a minimalist store with selectors, middleware support, and automatic re-render optimization. A typical Zustand store handles global state with straightforward subscription patterns:

React 19's approach shifts this pattern toward Context and Promises. The equivalent implementation leverages Context for state distribution and use() for async resolution:

Applications with multiple interconnected stores require a phased migration approach. The key challenge involves maintaining cross-store dependencies while transitioning to Context-based patterns.

Zustand excels at computed values through selectors. When a store calculates derived state from multiple sources, the migration needs to preserve these dependencies:

The React 19 equivalent separates data fetching from computation, using useMemo for derived values:

Zustand's subscription model provides fine-grained control over re-renders through selector functions. Components only re-render when selected state slices change:

Context-based approaches in React 19 require more deliberate optimization. Without proper memoization, every Context consumer re-renders when any value changes. The solution involves splitting Contexts by update frequency:

This pattern mirrors Zustand's efficiency by ensuring components only subscribe to the specific data they need.

Zustand's middleware ecosystem provides persistence, immer integration, and DevTools support out of the box. Teams migrating away from these features need alternative solutions.

For persistence, React 19 applications can implement custom hooks that sync Context state with localStorage:

DevTools integration requires more effort. The React DevTools can inspect Context values, but lack Zustand's time-travel debugging. For complex applications, maintaining a thin Zustand layer for debugging while using React 19 patterns for new features provides a pragmatic transition path.

Certain scenarios favor keeping Zustand despite React 19's new capabilities. Applications with complex state machines, heavy cross-component coordination, or extensive middleware dependencies may find the migration cost outweighs the benefits.

Zustand's external store subscription model enables state access outside React components, useful for WebSocket handlers, service workers, or utility functions. React Context requires component boundaries, making non-component state access more cumbersome.

Performance-critical applications with hundreds of components subscribing to different state slices benefit from Zustand's selector optimization. While Context splitting achieves similar results, it requires more architectural planning and boilerplate.

Start by identifying stores with minimal dependencies and straightforward async operations. These candidates migrate cleanly to use() and Context patterns. Convert one store at a time, maintaining parallel implementations during the transition to ensure stability.

For stores with complex interdependencies, consider a hybrid approach: keep Zustand for core state management while using use() for new async features. This incremental strategy reduces risk and allows teams to evaluate performance characteristics before committing fully.

The use() hook represents a significant step toward standardizing async state patterns in React. Teams should evaluate their specific requirements—considering bundle size, performance needs, and development velocity—before deciding whether migration delivers meaningful value over Zustand's proven approach.

Migrating from Zustand to React 19's use() Hook

The React state management landscape has evolved significantly, with lighter alternatives challenging Redux's dominance. Zustand, Jotai, and Valtio represent three distinct approaches to state management, each optimized for different use cases. Understanding their architectural differences helps teams choose the right tool for their specific requirements.

Each library takes a fundamentally different approach to state management. Zustand uses a centralized store pattern with hooks, Jotai embraces atomic state with bottom-up composition, and Valtio leverages proxy-based mutable updates with immutable snapshots.

Zustand implements a minimal flux-like pattern without boilerplate. The store is a hook that components can subscribe to, with automatic re-renders when selected state changes. The API surface is deliberately small—create a store, use the hook, update state.

The selector pattern is critical for performance. Without it, components re-render on any state change. Zustand uses shallow equality comparison by default, so returning new objects from selectors can cause unnecessary renders.

Jotai's atom-based model breaks state into minimal units that compose together. Each atom is an independent piece of state with its own subscribers. Derived atoms automatically recompute when dependencies change, similar to computed values in MobX or signals in SolidJS.

The atomic model excels at fine-grained reactivity. Components subscribe only to the atoms they use, eliminating manual selector optimization. Derived atoms form a dependency graph that automatically updates when source atoms change.

Valtio: Mutable API with Immutable Benefits

Valtio uses ES6 Proxies to track mutations and convert them to immutable updates. Developers write mutable-style code, but the library ensures immutable state updates under the hood. This approach feels natural for developers coming from Vue or MobX.

The proxy tracks which properties components access during render. Only components accessing changed properties re-render. This automatic tracking eliminates selector functions entirely, though it requires understanding how proxy-based reactivity works.

Bundle size matters for initial load performance. Zustand weighs approximately 1.1KB gzipped, Jotai around 2.9KB, and Valtio roughly 3.5KB. These differences are minimal in most applications, but can matter in bundle-size-constrained environments.

Runtime performance depends heavily on usage patterns. Zustand requires manual selector optimization to prevent unnecessary renders. A poorly written selector that returns new objects on every call defeats the optimization entirely:

Jotai's atomic model provides automatic optimization. Components re-render only when atoms they read change. The trade-off is more atoms to manage and understand dependency relationships between them.

Valtio's proxy-based tracking offers the best developer experience for fine-grained updates but can be harder to debug. Proxy behavior isn't always intuitive, especially with nested objects or arrays.

Zustand works well for applications with clear state boundaries and predictable update patterns. E-commerce applications, dashboards, and form-heavy interfaces benefit from its straightforward API. The middleware ecosystem (persist, devtools, immer) handles common requirements without additional dependencies.

Jotai excels in applications requiring complex derived state or real-time updates. Consider a collaborative editor where multiple users edit different parts of a document. Each section can be an atom, with derived atoms computing aggregate state. Components subscribe only to relevant atoms, minimizing re-renders as users type.

Valtio fits applications with deeply nested state or frequent small updates. Configuration panels, game state, or complex form wizards benefit from the mutable API. The ability to mutate nested properties directly reduces boilerplate:

All three libraries integrate cleanly with React 18's concurrent features. Zustand supports React 18 out of the box with proper use of useSyncExternalStore. Jotai and Valtio both handle concurrent rendering correctly, though Valtio requires React 18+ for optimal performance.

TypeScript support varies. Zustand requires explicit typing for stores but provides excellent inference once set up. Jotai offers strong typing with minimal boilerplate—atoms infer types from initial values. Valtio's proxy-based approach can challenge TypeScript, especially with complex nested structures.

DevTools integration exists for all three. Zustand's Redux DevTools middleware provides time-travel debugging. Jotai offers a DevTools package with atom inspection. Valtio includes built-in DevTools support showing proxy state changes.

Server-side rendering requires different approaches. Zustand needs manual hydration of initial state. Jotai provides a Provider component for SSR with proper hydration. Valtio supports SSR but requires careful handling of proxy initialization on the server.

Choose Zustand for applications needing a Redux-like pattern without boilerplate. Teams familiar with Redux will find the mental model comfortable. The middleware ecosystem handles persistence, logging, and other cross-cutting concerns.

Choose Jotai when fine-grained reactivity matters and the application has complex derived state. The atomic model scales well as applications grow, and the bottom-up composition prevents tight coupling between state pieces.

Choose Valtio when developer experience and rapid iteration are priorities. The mutable API reduces cognitive load, especially for developers from Vue or Angular backgrounds. Be prepared to understand proxy behavior and potential edge cases.

None of these libraries locks teams into specific patterns. Applications can mix approaches—using Zustand for global app state while Jotai manages form state, for example. The lightweight nature of all three makes experimentation low-risk.

The React state management ecosystem continues evolving. These libraries represent current best practices, but requirements change. Evaluate based on team familiarity, application complexity, and performance needs rather than popularity metrics alone.

Zustand vs Jotai vs Valtio: Performance Guide 2025

, the React team just dropped the stable 1.0 release of the React Compiler. This is huge - we've been testing the beta for months now, and seeing it hit stable means it's production-ready for the rest of us.

The React Compiler is essentially an automatic optimization layer that handles memoization for you. Instead of manually wrapping everything in useMemo, useCallback, and React.memo, the compiler analyzes your components at build time and inserts these optimizations where they'll actually help.

I've been running the beta on a few production apps since earlier this year, and the difference is real. One dashboard component I was working on had about 12 different useMemo calls scattered around - the kind of stuff you add because you know you should, but it makes the code harder to read. With the compiler, I ripped all that out and let it handle the optimization. Bundle size stayed roughly the same, but the code is way cleaner.

The 1.0 release means they've stabilized the API and committed to backwards compatibility. No more breaking changes between versions, which was honestly the biggest blocker for adoption. The beta was solid but you never knew if an update would break your build.

Here's the thing - this isn't just about removing useMemo calls. It fundamentally changes how we think about React performance.

For the past few years, we've been trained to think about optimization as something you add manually. You profile your app, find the slow parts, add memoization, repeat. It works but it's tedious and you end up with optimization code cluttering your business logic.

The compiler flips this model. You write straightforward React code and the compiler figures out what needs optimization. It's not magic - it's static analysis and code transformation - but the effect feels like magic when you're working with it.

I tested this on a data table component that was re-rendering way too often. Before the compiler, I had something like this:

Same performance characteristics, way more readable. The compiler inserts the memoization where it matters.

The biggest win is for teams. Code reviews get easier because you're not debating whether something needs useMemo or not. Junior devs can write performant code without understanding all the memoization rules. Senior devs spend less time optimizing and more time building features.

But there are gotchas. The compiler is smart but it's not psychic. It can't optimize across module boundaries unless you're using ES modules properly. And it makes assumptions about your code - if you're doing weird stuff with refs or breaking React's rules, the compiler might not catch it.

I ran into this with a component that was mutating state directly (yeah, I know). The compiler optimized it assuming immutability, which made the bug harder to track down. Once I fixed the mutation, everything worked fine. The compiler enforces good practices by assuming you're following them.

Performance-wise, I'm seeing about 15-20% reduction in unnecessary re-renders on our larger apps. That's not revolutionary but it's noticeable, especially on lower-end devices. More importantly, it's consistent - the compiler applies optimizations uniformly across your codebase.

Build times go up slightly - maybe 10-15% in my testing. The compiler has to analyze your code, which takes time. For most apps this is negligible, but if you're already pushing 2-3 minute builds, you'll notice it.

 walks through setup, but here's what worked for me:

If you're using Next.js 15 or later, there's built-in support. Just enable it in your config:

Start with a small component or feature branch. Don't just flip it on for your entire app immediately. I spent about a week testing it on non-critical features before rolling it out wider.

The compiler will warn you about code it can't optimize. Pay attention to these warnings - they usually point to patterns you should fix anyway. Things like:

One thing I wish I'd known earlier: the compiler works best with TypeScript. It uses type information to make better optimization decisions. If you're still on JavaScript, you'll get fewer optimizations.

Real talk - you might not need this yet if:

- You're on React 17 or earlier (compiler requires 18+)

- Your app is small and already performs fine

- You're using a lot of class components (compiler focuses on hooks)

- Your build pipeline is already complex and fragile

The compiler adds complexity to your build process. For small projects or prototypes, manual optimization might be simpler. I'm keeping it off my side projects because the setup overhead isn't worth it.

Also, if you're using a lot of third-party component libraries, check their compatibility first. Most modern libraries work fine, but older ones might have issues.

The 1.0 release is just the starting point. The React team has hinted at more aggressive optimizations coming in future versions - things like automatic code splitting and better tree shaking.

What excites me most is that this moves React closer to the "just write code and it'll be fast" model that frameworks like Svelte have been pushing. We're not there yet, but we're getting closer.

For production apps, I'd say wait a month or two to let the community shake out any edge cases, then start planning your migration. For new projects starting today, absolutely use it from day one.

The compiler isn't going to solve all your performance problems - you still need to understand React's rendering model and write good code. But it removes a lot of the manual optimization work that's been part of React development for years. That's a win in my book.

Sarah Chen

Turbopack's Zero-Work Strategy: Build Less, Ship Faster

Migrating from Zustand to React 19's use() Hook

Zustand vs Jotai vs Valtio: Performance Guide 2025

React Compiler 1.0: Performance Gains Without the Hype