Vite 8 Lands Rolldown, React Router Gets RSC, and Remix 3 Takes Shape
Published on 10.04.2026
Vite 8 Ships Rolldown as Its Single Unified Bundler
TLDR: Vite 8 replaces the dual esbuild/Rollup architecture with Rolldown, a single Rust-based bundler that delivers 10-30x faster production builds while maintaining full plugin compatibility with the existing Vite ecosystem.
Summary: Vite made a pragmatic architectural decision when it launched: use esbuild for development speed and Rollup for production builds. That bet worked well for years, but it created a fundamental tension — the two bundlers had different plugin APIs, different behaviors, and different performance characteristics. Any non-trivial Vite plugin had to account for both paths. Vite 8 ends that tension by shipping Rolldown as the single, unified bundler for both development and production.
Rolldown is a Rust implementation of a Rollup-compatible bundler, developed by the Vite team at VoidZero. The migration to a Rust-based core is significant because it removes the JavaScript overhead in the build pipeline. The 10-30x faster builds claim comes from benchmarks on real projects, not toy examples — though as always, your mileage will vary based on project complexity, plugin usage, and the specific operations being measured.
The critical part for adoption is the plugin compatibility guarantee. The Vite team has invested heavily in making sure Rolldown accepts the same Rollup plugin API that the ecosystem has built against. That means popular plugins — vite-plugin-react, unplugin-icons, and hundreds of others — should work without modification. This is the most important factor for whether teams can upgrade without ceremony, and early reports suggest the compatibility layer is solid.
The launch of registry.vite.dev alongside Vite 8 is a quiet but useful addition. As the Vite plugin ecosystem has grown to thousands of packages, discoverability has become a real problem. The searchable directory aggregates plugin metadata daily from npm, giving you a maintained index rather than relying on GitHub search or word of mouth.
Vite is now at 65 million weekly downloads, which puts it squarely in the infrastructure tier of the JavaScript ecosystem. Changes here ripple everywhere.
Key takeaways:
- Rolldown replaces esbuild + Rollup with a single Rust-based bundler
- 10-30x faster production builds, with development speed maintained or improved
- Full Rollup plugin API compatibility — existing plugins should work without changes
- registry.vite.dev launches as a searchable plugin directory
Why do I care: This is one of the most significant Vite releases since version 2. Moving to a single unified bundler removes an entire class of "works in dev, breaks in build" bugs that have plagued complex Vite setups. The Rust-based core means the performance ceiling is now much higher — teams with large monorepos that have been on the edge of making Vite work are going to find Vite 8 substantially more tractable. The migration path looks clean, which is the most important thing.
React Router Adds Experimental RSC Support
TLDR: React Router now has experimental React Server Components support in both Framework and Data modes, with template projects available for quick starts. The implementation is subject to breaking changes and requires careful version pinning.
Summary: React Router is making a move that many in the community have been waiting for: bringing React Server Components support into the framework. This is experimental — that warning appears prominently in the docs, and breaking changes in minor and patch releases are explicitly possible. If that risk profile concerns you, wait. If you're building something where you need RSC today and want React Router as the framework layer, this is the path.
The implementation supports both Framework Mode and Data Mode, which maps to the existing Router split between convention-based and configuration-based setups. In Framework Mode, RSC is wired up through an unstable Vite plugin that integrates the experimental React RSC Vite plugin. In Data Mode, you get the same Vite plugin but with configuration-based routing. Templates for both exist and can be scaffolded with create-react-router.
What React Router's RSC implementation gives you is the standard RSC feature set: Server Components that render on the server before bundling, Client Components via the use client directive, and Server Functions via use server. The Server Functions piece is particularly interesting because it's React Router's take on what were previously called "actions" — callable server-side functions that can be invoked from client components.
The honest assessment here is that RSC in any framework is still maturing. The React team has been clear that the primitive APIs are stable but the integration patterns are not. React Router building on top of an experimental Vite plugin means there are two layers of instability stacked on each other. For production use cases, this warrants caution.
Key takeaways:
- RSC support is experimental; expect breaking changes in minor/patch releases
- Available in both Framework Mode and Data Mode
- Templates available via
npx create-react-router@latest --template remix-run/react-router-templates/unstable_rsc-framework-mode - Server Components, Client Components, and Server Functions all supported
Why do I care: React Router bringing RSC support is architecturally significant because it gives the framework a first-class server/client boundary that doesn't depend on a meta-framework like Next.js. The experiment is worth following. The caution flag around using it in production today is real, and I'd be hesitant to build anything business-critical on two stacked experimental layers. But for greenfield projects where you can absorb breaking changes, this is worth exploring.
React Server Components — React Router
React Router v8 Future Flags: Middleware and Route Module Splitting
TLDR: React Router v7's future flags for v8 include middleware support for request/response lifecycle hooks and route module splitting to reduce client bundle sizes. Both can be adopted incrementally today.
Summary: The future flags system in React Router is how the team ships breaking changes incrementally — you opt in to v8 behavior in your v7 app, stabilize it, then the next major version just makes those flags the default. Two flags are particularly interesting right now.
The v8_middleware flag introduces a request/response lifecycle layer that runs before and after your loaders and actions. This is a well-understood pattern from server frameworks: you want a place to run authentication checks, logging, CORS handling, and error normalization without repeating that logic in every route. React Router has historically handled some of these cases via the existing loader chain, but middleware gives you a cleaner cross-cutting concern model. The implementation involves a getLoadContext pattern that feels familiar to anyone who's worked with Express middleware.
The v8_splitRouteModules flag addresses a real bundle size problem in framework-mode apps. React Router's convention-based routing currently bundles all route exports — including server-only code — into the client bundle. Module splitting separates the client-facing exports from the server-only ones, reducing what gets shipped to the browser. For large apps with many routes and significant server-side logic, this can meaningfully reduce initial load time.
Both flags can be adopted route by route, which means you don't need a big-bang migration. You enable the flag, update the routes that benefit most, and leave the rest for later.
Key takeaways:
v8_middlewareadds before/after hooks for authentication, logging, CORS, and similar cross-cutting concernsv8_splitRouteModulesseparates client and server route exports to reduce bundle size- Both flags are available today in v7 and become defaults in v8
- Incremental adoption — no all-at-once migration required
Why do I care: The middleware flag is the one that excites me more because it solves a real pattern problem. Every app I've worked on has had some version of "run auth before this loader" logic, and it's always been a bit awkward in React Router. A proper middleware layer makes that clean. The route module splitting is important for performance at scale — if your app has 200+ routes with complex server logic, this is a meaningful optimization.
Future Flags and Deprecations — React Router
Remix 3 Alpha.4: Data Table API Overhaul and Auth Middleware
TLDR: Remix v3.0.0-alpha.4 includes breaking changes to the data-table SQL API, consolidating QueryBuilder into a simpler Query interface, and adds CORS middleware, auth middleware, and frame navigation APIs.
Summary: Remix 3 is still in alpha but moving fast, and alpha.4 includes some significant API surface changes that are worth understanding if you're tracking the project. The data-table module gets the most attention in this release, with a breaking change that removes the QueryBuilder class in favor of a simpler Query and db.exec() pattern.
The reasoning behind the QueryBuilder removal is worth paying attention to. The old API created a proliferation of types — QueryBuilder, QueryMethod, separate command descriptor types for first(), count(), insert(), and update(). The new pattern consolidates these into Query objects that all go through db.exec(), which is simpler to reason about and easier to type correctly. The db.query(table) shorthand still exists for convenience, but it now returns the same Query class as everything else.
The auth and CORS middleware additions via package re-exports (remix/auth, remix/auth-middleware, remix/cors-middleware) follow the composable middleware architecture that Remix 3 is building toward. Rather than baking auth into the framework, they provide well-tested primitives you wire together. The browser-origin and CSRF protection middleware addition is the kind of security default that should probably be included in most apps but often gets added as an afterthought.
The frame navigation APIs in remix/component and remix/component/server are the most unfamiliar surface in this release — this looks like the groundwork for multi-frame application architectures, where different parts of a page can have independent navigation histories.
Key takeaways:
- Breaking change:
QueryBuilderremoved; useQuery+db.exec()instead - New package re-exports:
remix/auth,remix/auth-middleware,remix/cors-middleware - CSRF protection and browser-origin middleware added
- Frame navigation APIs for multi-frame application architectures
Why do I care: Remix 3 is in alpha for a reason — the API surface is still being worked out. But the direction is clear: a composable, modular framework that gives you the pieces to assemble what you need rather than a monolithic set of conventions. The data-table API simplification is the right call, even if it's a breaking change. If you're building something new and want to be on the frontier of where React web frameworks are going, Remix 3 is worth tracking. Just don't build a customer-facing system on alpha software.