Remix 3 ditched React: Should you stick with it?

Remix 3 is here, and it feels like a framework teleported from an alternate timeline — one where React Hooks never happened. It’s a complete rewrite of the Remix web framework that abandons React entirely in favor of a simpler, imperative programming model built on web standards.

It’s not a version bump; it’s a ground-up rewrite that swaps React for a fork of Preact. Early prototypes from the Remix Jam conference suggest a more imperative model of direct state updates instead of useState, and native browser events instead of props. Though official documentation hasn’t been released yet, this shift is such a radical departure that it begs the question: why even call it Remix?

This has, predictably, created a schism in the community. Developers are asking what’s going on — especially with the highly controversial new guiding principle: being “LLM-friendly.”

But we’ve seen this movie before.

In 2016, the Angular team ignited a firestorm by announcing a complete, non-backward-compatible rewrite. Developers were furious. They wrote “break-up letters.” It was a mess — but in hindsight, the painful leap from AngularJS to Angular 2+ was a necessary, and ultimately successful, modernization.

So, is Remix 3 making the same gamble?

Throughout this article, we’ll explore this controversial reboot, clarify the two paths forward, and compare the new philosophy to the React world it’s leaving behind. Ultimately, we’ll ask: is this a brilliant return to web fundamentals or a misguided step that will alienate its user base?

The great schism

When the team announced Remix 3, they also clarified the merger with React Router. For existing Remix developers, this means there isn’t just one path forward — there are two.

The “stay” path: React Router v7 (the real Remix v2)

This is the stable, intended upgrade path for most Remix v2 users. The features you love — loaders, actions, route-based data fetching — have been merged directly into React Router v7. It’s essentially Remix v2 rebranded as “React Router framework mode.”

The “move” path: Remix v3 (the experimental rewrite)

This is the new framework — not an upgrade, but a complete React-less rewrite using a new philosophy (Preact fork, this.update(), imperative model). It represents a total break from the past.

Understanding this split is critical. You’re not being forced to migrate to Remix v3 — you’re being given a choice.

The “old vs. new” shift in philosophy

This is where the debate gets heated. Remix v3 isn’t just a library change — it’s a rejection of the React-centric, declarative model developers have spent the last decade mastering.

A quick note: at the time of writing, there are no official technical docs. What we know comes from code shown at the Remix Jam 2025 conference and early community analysis. The specific APIs and architecture are still in flux, so we’ll focus on the conceptual models the team has described.

React’s declarative model — “complexity as capability” — describes the state we want and lets React’s VDOM and Hooks (useState, useEffect) make it happen.

Pros: A powerful, state-driven model with a massive ecosystem.
Cons: The “ugly soup of useEffects” that both humans and LLMs struggle to reason about. Remix v3 is running from this growing complexity — React Server Components, use client, hydration, and more.

Remix v3 bets that the React model is the wrong abstraction and charts a new “web-first” approach built on imperative principles.

From useState → this.update()

<class="language-javascript hljs">
// React/Remix v2 approach
function Counter() {
  const [count, setCount] = useState(0);
  
  return (
    <div>
      <div>{count}</div>
      <button onClick={() => setCount(c => c + 1)}>
        Increment
      </button>
    </div>
  );
}

And based on code shown at Remix Jam, in Remix v3’s early prototypes, the same component looks like this:

<class="language-javascript hljs">
// Remix v3 prototype (shown at Remix Jam 2025)
function Counter(this: Remix.Handle) {
  let count = 0; // Plain closure variable, no useState

  return () => (
    <div>
      <div>{count}</div>
      <button onClick={() => {
        count++;
        this.update(); // Explicit re-render command
      }}>
        Increment
      </button>
    </div>
  );
}

Instead of React tracking state changes, you explicitly tell the framework when something has changed. State can live in plain closure variables.

From props → native browser events

Rather than passing data down a component tree, the new model encourages CustomEvent for communication. A child dispatches an event; a parent listens for it.

From RSC → HTML-based boundaries

For server-client communication, Remix v3 takes a “less magical than RSC, more like HTMX” approach, using HTML as the wire format with async boundaries. The goal: leverage the web platform instead of reinventing it.

This represents a full paradigm shift — trading React’s declarative magic for a more explicit, imperative, and (in their view) simpler set of primitives.

Deconstructing Remix v3’s four principles (and why one sparked controversy)

The Remix team outlined four core principles guiding v3’s development. Three are straightforward; one has become a lightning rod for criticism.

1. Model-first development (the LLM controversy)

• The claim: Code should be optimized for Large Language Models (LLMs) to read, understand, and write.
• The backlash: Critics see this as chasing VC trends rather than solving developer pain points. As one Reddit user put it: “Is there anyone who hasn’t taken VC money that cares about LLMs?”
• The defense: “LLM-friendly” might be shorthand for simplicity. LLMs (and humans) struggle with deeply nested React code. A simpler, imperative API could improve both AI and human productivity. Whether that trade-off is worth the baggage is up for debate.

2. Prioritize web APIs & 3. Avoid dependencies

These principles form the stronger philosophical foundation. The goal is to stop relying on React — a critical dependency the team doesn’t control.

By building on web primitives like Request, Response, FormData, and CustomEvent, Remix 3 aims to be the web, but with a framework — not a framework that happens to run on the web.

4. Religiously runtime (over build steps)

This is a direct shot at the Vercel/Next.js ecosystem and its complex build pipelines. Remix v3 promises “zero build time” and “disgustingly fast” performance through edge-first, runtime-first execution.

It’s a compelling vision — if developers can stomach the LLM principle that comes with it.

We’ve seen this before: the AngularJS parallel

Before passing judgment, let’s acknowledge the community’s frustration: churn fatigue is real.

For years, the React Router team (also behind Remix) has been notorious for sweeping, non-backward-compatible API changes. As one Hacker News user wrote: “I have never, in my entire career, seen a library change as many times as React Router.”

But this isn’t new — it mirrors the AngularJS → Angular rewrite.

• The rewrite: In 2016, Google announced Angular 2 as a total rewrite.
• The backlash: Developers were furious, stranded after migrating to AngularJS.
• The confusion: Even the naming (AngularJS vs. Angular) caused chaos.

The parallels are striking. Remix is asking for the same leap of faith.

Angular eventually emerged stronger, but it had Google’s resources and brand to survive the outrage. Shopify (Remix’s owner) doesn’t have that luxury. The stakes are higher, and the margin for error smaller. To succeed, Remix 3 must prove its value immediately — not years later.

Conclusion: Should you stick with Remix?

It depends on what “Remix” means to you.

• For existing Remix/React developers: Stick. with React Router v7. It’s the stable, proven Remix philosophy in a React-native form. Ignore the Remix v3 noise for now.
• For the churn-fatigued: Bail. If you’re exhausted by breaking changes, take this as your cue to explore stable alternatives like TanStack Router.
• For the curious: Wait and watch. Remix v3 is bold and fascinating — but it’s research, not production-ready. Don’t bet your product on it yet.

Ultimately, the question isn’t whether the technology will work — it’s whether the Remix community will survive long enough to see its own vindication.

The post Remix 3 ditched React: Should you stick with it? appeared first on LogRocket Blog.

This post first appeared on Read More