Remix 3 Dumped React and I'm Not Sure Who It's For

Somewhere around mid-2025, the Remix team looked at the framework they'd spent years building on React and decided to burn it down. Not refactor it. Not gradually deprecate pieces. They forked Preact, ripped out the virtual DOM, replaced hooks with closure variables, and called it Remix 3. There is explicitly no migration path from Remix 2. Their words, not mine.

I've been sitting with this for a few months now, watching the preview evolve, and I keep going back and forth between "this is brave" and "this is a vanity project." Let me walk through what actually changed and whether any of it matters for your next project.

#What Remix 3 Actually Is

Remix 3 is not a major version bump. It's a ground-up rewrite that shares a name with its predecessor and almost nothing else.

The rendering engine swaps React for a custom component model built on a Preact fork. No virtual DOM. No useState. No synthetic events. State lives in plain closure variables, and when you want the UI to update, you call this.update() explicitly. Components communicate upward via native browser CustomEvent dispatching instead of callback props.

Routes are defined in code rather than file conventions:

export const routes = route({
  books: {
    index: "/books",
    show: "/books/:slug"
  }
});

// Type-safe URL generation — this is genuinely nice
routes.books.show.href({ slug: "gatsby" });

The loader/action pattern survives, but now it's raw HTTP method handlers returning standard Response objects:

export const handlers = {
  async GET({ params }) {
    const post = await getPost(params.slug);
    return render(<PostPage post={post} />);
  },
  async POST({ request }) {
    const form = await request.formData();
    await saveComment(form.get("comment"));
    return redirect("/posts");
  }
};

No use server. No use client. No Server Components. Just functions that handle HTTP verbs and return responses. If you've ever written a Hono or Express handler, this looks familiar.

#The "Frames" Concept

The most interesting new primitive is Frames — isolated page sections that load and update independently. When a Frame refreshes, the server sends an HTML fragment that gets patched directly into the DOM. Think HTMX-style partial updates, but integrated into the framework's routing layer.

This sidesteps the entire React Server Components complexity. No streaming suspense boundaries, no serialization protocol between server and client components. The server renders HTML. The browser receives HTML. Revolutionary stuff if you squint hard enough to forget that PHP did this twenty years ago.

I'm being unfair — Frames compose with client-side navigation and maintain scroll position, which is more than a raw HTMX setup gives you. But the pitch of "we solved the server/client split" deserves some skepticism when the solution is "just send HTML fragments."

#The Six Principles (and the Controversial One)

Ryan Florence and Michael Jackson laid out six guiding principles for the rewrite. Most are reasonable web-standards-first stuff: build on Fetch API primitives, avoid dependencies, prefer runtime behavior over build-time magic.

Then there's principle number one: Model-First Development — optimizing code for LLM readability.

This is where the community split happened. The stated goal is that AI coding assistants can understand and generate Remix 3 code more easily because it's closer to web primitives. Critics immediately called it "chasing VC trends," and honestly? I get the skepticism. Designing a framework around what makes GPT-4 comfortable writing code feels like optimizing for the wrong user.

But there's a kernel of truth buried under the hype. Framework-specific abstractions are harder for AI tools to work with. Anyone who's watched Copilot hallucinate nonexistent Next.js APIs knows this. Whether that justifies a complete rewrite is a different question.

#The Migration Problem

Here's where it gets rough for existing Remix shops. The upgrade path from Remix 2 is... React Router v7. That's it. React Router absorbed all of Remix's patterns — loaders, actions, nested routing — and that's where your production app should go.

Remix 3 is a different framework that happens to share a brand. If you want to adopt it, you're rewriting your app. New component model, new state management, new event system, new routing definitions.

The team is upfront about this, which I respect. They're not pretending it's a smooth upgrade. But it does raise the question: if your existing users can't follow you, who's your audience?

#Who Should Care

Remix 3 makes the most sense if you're starting a new project in 2026 and you're already frustrated with the React ecosystem's complexity. No build step requirement. No hydration mismatch debugging. No "use client" boundary whack-a-mole. Standard Request/Response everywhere, deployable on Node, Deno, or Bun without adapters.

It's a bet on simplicity. The framework is targeting developers who think React Server Components went too far in the wrong direction — more moving parts, more mental overhead, more things that can break in ways you can't debug without understanding the framework's internals.

The problem is adoption math. Eighty-four percent of developers use tools built for React. The component library ecosystem, the hiring pipeline, the Stack Overflow answers — all of it assumes React. Remix 3's Preact fork means most React libraries won't work without modification. You're opting into a smaller world.

#My Honest Take

I like the technical ideas. Explicit this.update() over magic re-renders appeals to the part of my brain that spent years debugging unnecessary React renders. Frames are a clean abstraction. Type-safe route generation is overdue across the ecosystem.

But I've been through enough framework rewrites to know that technical elegance doesn't win adoption battles. Remix 3 needs to be dramatically better to overcome the ecosystem gap, and right now it's "interesting and different" — which isn't the same thing.

If you're building a side project, try it. The DX is genuinely refreshing. If you're making production decisions for a team, stick with React Router v7 and check back in six months. The framework needs time to prove that "model-first development" means something beyond a pitch deck bullet point.