Get AI summaries of any video or article — Sign up free
Remix is ditching React (and I think that's a good thing) thumbnail

Remix is ditching React (and I think that's a good thing)

Theo - t3․gg·
6 min read

Based on Theo - t3․gg's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Remix v3 will not be built on React; it will use a fork of Pact to own more of the stack.

Briefing

Remix is making a dramatic break from React: Remix v3 will be built without React, using a fork of Pact instead. The shift matters because it signals a broader reset in how full-stack web frameworks might be designed—less as “React plus routing plus bundling,” and more as a framework that owns the full stack, aligns tightly with web standards, and is ready for new interaction models driven by AI.

The story starts with Remix’s origin as a React-focused upgrade path. Remix grew out of React Router’s limitations: React Router turned URLs into the right UI, but the React ecosystem lacked a cohesive, recommended “full-stack” approach. React Router itself was created by Michael Jackson and Ryan Florence, who came from the Ember community and built routing for React to fill gaps around performance and page-level rendering. Despite React Router’s dominance, the React team never officially endorsed it—never included in create React app and not highlighted in React docs—creating long-running resentment in the community.

Remix initially tried to fix the “React at scale” pain companies were hitting: slow builds, unreliable hot reloads, and data-fetching patterns that caused waterfall delays. It began as a paid, closed-source template alternative to create React app, betting heavily on modern tooling like esbuild and on route-level data loaders that moved fetching logic out of components and into the routing layer. That approach made Remix feel like “React Router, but for the whole stack,” with server-side rendering patterns designed to improve SEO and performance.

Over time, Remix’s business model and architecture collided with market realities. Next.js surged, and Shopify acquired Remix to support its own React-based direction—especially after Shopify’s Hydrogen project ran into trouble with early server component assumptions. After the acquisition, Remix effectively got absorbed into React Router’s evolution: React Router V7 absorbed the bundler and server runtime pieces, added server component support, and created a migration path for Remix users. That success also meant Remix v2 became a thin wrapper—and Remix was effectively put to sleep to make room for a new iteration.

The new plan, laid out in “Wake up Remix,” reframes the framework as a full-stack platform rather than a React-adjacent wrapper. React Router V7 is positioned as the stable, battle-tested home for server component adoption, with a smooth incremental path for existing Remix and React Router users. React Router’s governance is also shifting toward open governance to avoid single-vendor control, and it’s already powering major production apps across Shopify and other well-known sites.

Remix v3 then uses that freedom to pursue a different foundation: owning critical dependencies (including avoiding React), minimizing reliance on compiler tricks, and keeping runtime behavior close to source code. The framework’s design principles emphasize model-first development for LLM-driven UX and developer workflows, heavy use of web APIs to avoid server/client divergence, strict composition rules for replaceable abstractions, and a cohesive distribution model that packages the ecosystem into a single toolbox. The result is a bet that the next decade of web frameworks should rethink the route-to-response model from first principles—potentially making it easier for both humans and AI systems to build and stream modern experiences.

Cornell Notes

Remix v3 is set to break from React entirely, built on a fork of Pact rather than React. The change follows Remix’s earlier arc: it started as a paid, React-centric alternative to create React app, then gradually merged into React Router’s evolution after Shopify acquired it. React Router V7 now carries the server component momentum with an incremental adoption path, and it’s moving toward open governance to keep it community-driven. With Remix no longer tied to React or a specific paradigm, the framework aims to own the full stack—minimizing compiler magic, leaning on web APIs, and designing for AI-era interaction patterns. The move could reshape expectations for what a “web framework” should be beyond React-based routing and rendering.

Why did Remix originally exist, and what problem did it try to solve for React teams?

Remix began as a “better starting point” for large React projects. It targeted pain seen in companies using React Router and React at scale: slow compilation times, hot reloads that didn’t work reliably, and data-fetching patterns that created waterfall delays in the browser. Remix also pushed fetching logic upward into route-level loaders instead of leaving it inside components, aiming for more predictable server rendering and performance.

What was the relationship between React Router and Remix, and how did Remix end up “killed” in practice?

Remix largely stemmed from React Router’s need to map URLs to the right UI, but Remix tried to expand that idea into a full-stack framework. After Shopify acquired Remix, the bundler and server runtime pieces were moved into React Router V7, and Remix became a thin wrapper. That migration path let Remix users move onto React Router V7 (including server component support), which effectively reduced Remix’s standalone role—creating space for a reimagined Remix v3.

How did React Router become so dominant even without official React endorsement?

React Router was built by Michael Jackson and Ryan Florence, early adopters from the Ember community who wanted a missing piece for React: routing that turns URLs into components. It became ubiquitous—roughly six out of ten React apps using it and many React installs pulling in React Router as well. Yet the React team never officially recommended it: it wasn’t included in create React app and wasn’t highlighted in React docs, which created resentment despite its widespread use.

What does React Router V7 add that matters for server components and Remix users?

React Router V7 provides server component support with an incremental adoption path. It supports returning server components directly from loaders and actions and includes a first-class story for server-only routes. The goal is to let existing Remix V1/V2 and older React Router users move forward without a disruptive rewrite, while React Router becomes the stable platform for long-term server component evolution.

What’s the core technical shift in Remix v3, and why is Pact central to it?

Remix v3 is designed to own the full stack without relying on React or other critical dependencies they don’t control. It starts from a fork of Pact, a mature virtual DOM library already used heavily at Shopify and Google. The emphasis is on keeping the runtime close to the source code—avoiding compiler tricks that require delicate bundler interventions—so the framework can better control behavior across server and browser.

How do Remix v3’s principles connect to AI-era development?

Remix v3’s “model-first development” principle treats LLMs as a fundamental part of both user experience and developer workflows. It calls for optimizing source code, documentation, tooling, and abstractions for LLMs—not just humans—and for building product abstractions that use models directly. It also argues that common frameworks struggle with AI streaming and token-by-token UI updates, so a framework designed from the start for these primitives could perform and feel better.

Review Questions

  1. What specific pain points in React app development did Remix’s original design try to address, and how did route-level loaders change data-fetching behavior?
  2. How did Shopify’s acquisition alter the trajectory of Remix, and what role did React Router V7 play in absorbing Remix’s core runtime pieces?
  3. Which Remix v3 principles (model-first, web APIs, runtime closeness, composition) are most likely to improve AI streaming experiences, and why?

Key Points

  1. 1

    Remix v3 will not be built on React; it will use a fork of Pact to own more of the stack.

  2. 2

    Remix’s early identity was a paid, React-centric alternative to create React app, built around esbuild bets and route-level data loaders.

  3. 3

    Shopify’s acquisition shifted Remix’s core runtime into React Router V7, enabling Remix users to migrate and effectively pausing Remix as a standalone framework.

  4. 4

    React Router V7 now provides server component support with an incremental adoption path, including server-only routes and loader/action integration.

  5. 5

    React Router is moving toward open governance to keep it from being controlled by a small set of individuals or a single company.

  6. 6

    Remix v3’s design principles emphasize model-first development, heavy reliance on web APIs, minimal compiler magic, and strict composition rules for replaceable abstractions.

  7. 7

    Remix v3 aims to rethink the server-to-URL-to-response model from first principles, targeting both human and LLM workflows.

Highlights

Remix v3’s headline change is a clean break from React—built on Pact instead.
React Router V7 absorbed much of what made Remix valuable, including server component support and a migration path for existing Remix users.
React Router’s governance is shifting to open governance, positioning it as a community-run foundation rather than a single-vendor asset.
Remix v3 frames AI streaming and token-by-token UI updates as a first-class requirement, not an afterthought.

Topics

Mentioned