When the Remix team published their "Wake up, Remix!" blog post and subsequently unveiled Remix 3 at Remix Jam 2025, they did not just announce a new version of their framework. They declared independence from React. Remix 3 is a ground-up rewrite that replaces React with a fork of Preact, introduces an imperative state model, and builds directly on native web APIs. There is no migration path from Remix 2 or React Router v7.

This is not an incremental upgrade. It is a philosophical rupture -- and it might be the clearest signal yet that the JavaScript ecosystem is entering a post-React era.

What Exactly Is Remix 3?

Remix 3 is a complete reimagining of what a full-stack web framework should look like in 2026. Rather than building on top of React's component model and virtual DOM, the Remix team has created their own reactivity system from scratch, starting with a fork of Preact as a lightweight JSX runtime.

Core Architectural Changes

React model vs Remix 3 web standards architecture comparison The philosophical divide: React's Virtual DOM and hooks vs Remix 3's direct DOM and web standards

1. Preact Fork Instead of React

Remix forked Preact to create a minimal JSX runtime that uses web standards like View Transitions and declarative hydration. The fork gives the Remix team complete control over the rendering pipeline, cutting external dependencies to almost nothing.

// Remix 3: Components look like JSX but run on the Preact fork
// No useState, no useEffect -- explicit state management
export function Counter() {
  let count = 0;
  const el = document.getElementById("count-display");
  
  return (
    <div>
      <span id="count-display">{count}</span>
      <button onclick={() => {
        count++;
        el.textContent = count;
      }}>
        Increment
      </button>
    </div>
  );
}

2. Imperative State Model

Gone are useState and useReducer. In Remix 3, state lives in plain closure variables. You explicitly tell the framework when something has changed, rather than relying on React's reconciliation engine to detect changes.

// Remix 3 approach: Direct DOM updates, no virtual DOM diffing
function TodoList() {
  const todos = [];
  
  function addTodo(text) {
    todos.push({ text, done: false });
    // Explicitly update the DOM -- no re-render cycle
    document.getElementById("todo-list").innerHTML = 
      todos.map(t => `<li>${t.text}</li>`).join("");
  }
  
  return (
    <div>
      <ul id="todo-list"></ul>
      <form onsubmit={(e) => {
        e.preventDefault();
        addTodo(e.target.elements.text.value);
        e.target.reset();
      }}>
        <input name="text" required />
        <button type="submit">Add</button>
      </form>
    </div>
  );
}

3. Native Browser APIs as First-Class Citizens

Instead of wrapping browser APIs in framework abstractions, Remix 3 builds directly on:

  • Fetch API for data loading (Request, Response, URL objects)
  • Custom Events for component communication (instead of props drilling)
  • AbortSignal for cancellation
  • View Transitions API for page transitions
  • Web Components for encapsulation when needed

4. Server-First Architecture

Remix 3 doubles down on server rendering. The framework generates HTML on the server, ships minimal JavaScript to the client, and hydrates only the interactive parts of the page using declarative hydration patterns.

Why Remix Is Leaving React Behind

The Remix team has articulated several reasons for this dramatic shift:

Control Over the Full Stack

By owning the rendering layer, Remix can optimize the entire request-response lifecycle from server to client. With React, certain optimizations (like streaming HTML with interleaved data loading) required working around React's assumptions. With their own runtime, these optimizations are built in.

Web Standards Alignment

React's synthetic event system, virtual DOM, and component lifecycle hooks were originally created to smooth over browser inconsistencies that largely no longer exist. Modern browsers have converged on well-supported APIs. Remix 3 argues that building directly on these APIs produces faster, smaller, and more maintainable applications.

Bundle Size

The Remix 3 slim build comes in at roughly 19KB gzipped, compared to React + ReactDOM at approximately 42KB gzipped. When you factor in the elimination of many React-specific libraries (state management, routing wrappers, etc.), the savings compound.

Philosophical Divergence

React has been moving toward increasingly complex patterns -- Server Components, use() hooks, compiler-driven optimizations. The Remix team believes the web platform itself offers simpler solutions to the same problems.

What This Means for React Developers

If you are currently building with Remix 2 or React Router v7, here is the critical information you need.

There Is No Migration Path

The Remix team has been explicit about this: there is no automatic migration from Remix 2 / React Router v7 to Remix 3. The philosophies diverge too sharply for any reasonable migration tooling to bridge the gap. The two frameworks share a name and a team, but they are architecturally distinct projects.

Your Two Options

As a Remix/React developer, you now have two paths:

Path Framework Status React Compatible Best For
Stability React Router v7 Stable, production-ready Yes Existing apps, React ecosystem
Innovation Remix 3 Experimental, active development No New projects, web-standards purists

React Router v7 Is Not Going Away

React Router v7 represents the stable, production-tested version of the Remix philosophy built on React. It continues to be actively maintained and is the recommended choice for production applications today. If you have an existing Remix 2 app, upgrading to React Router v7 is the supported path.

When to Consider Remix 3

Remix 3 is compelling if:

  • You are starting a new project and want to bet on web standards
  • You are frustrated with React's growing complexity
  • Bundle size and performance are top priorities
  • You want zero dependency on React's release cycle
  • You are building content-heavy sites where server rendering dominates

When to Stay on React

Stick with React Router v7 (or Next.js, or another React framework) if:

  • You have a large existing codebase built on React
  • You depend on the React ecosystem (component libraries, state management tools, testing utilities)
  • You need production stability today -- Remix 3 is still experimental
  • Your team's expertise is deeply invested in React patterns

The Broader Framework Decoupling Trend

Framework decoupling trend from React dominance to post-React era The framework evolution: from React dominance (2015) to the web-standards-first post-React era

Remix 3 is not an isolated event. It is part of a broader trend in the JavaScript ecosystem where frameworks are decoupling from specific view layers.

Signals Everywhere

SolidJS, Svelte 5, Vue 3, and Angular have all converged on signal-based or fine-grained reactivity systems that do not require a virtual DOM. Remix 3's imperative state model is a variation on this theme.

Framework Agnosticism

Vite (the build tool) already supports React, Vue, Svelte, and Solid interchangeably. Astro lets you mix components from different frameworks on the same page. The idea that a framework must be tightly coupled to one view layer is increasingly seen as a limitation, not a feature.

The Web Platform as the Common Ground

The common thread across all these trends is the web platform itself. As browsers have become more capable and more consistent, the abstractions that frameworks provided have become less necessary. Features like:

  • CSS @scope and container queries (replacing CSS-in-JS)
  • The View Transitions API (replacing framework-specific page transition libraries)
  • Native <dialog> element (replacing modal libraries)
  • structuredClone() (replacing deep-clone utilities)
  • URLPattern (replacing routing libraries)

...are making it possible to build rich applications with fewer framework-specific dependencies.

Code Comparison: Remix 2 (React) vs. Remix 3

To make the differences concrete, here is the same feature -- a data-loading page with a form -- implemented in both frameworks:

Remix 2 / React Router v7 (React)

// app/routes/contacts.tsx (React-based)
import { useLoaderData, Form } from "@remix-run/react";

export async function loader() {
  const contacts = await db.contacts.findMany();
  return json({ contacts });
}

export async function action({ request }) {
  const formData = await request.formData();
  await db.contacts.create({
    data: { name: formData.get("name") }
  });
  return redirect("/contacts");
}

export default function Contacts() {
  const { contacts } = useLoaderData();
  
  return (
    <div>
      <h1>Contacts</h1>
      <ul>
        {contacts.map(c => (
          <li key={c.id}>{c.name}</li>
        ))}
      </ul>
      <Form method="post">
        <input name="name" required />
        <button type="submit">Add Contact</button>
      </Form>
    </div>
  );
}

Remix 3 (Web Standards)

// app/routes/contacts.tsx (Remix 3)
export async function loader({ request }) {
  const contacts = await db.contacts.findMany();
  return new Response(JSON.stringify(contacts), {
    headers: { "Content-Type": "application/json" }
  });
}

export async function action({ request }) {
  const formData = await request.formData();
  await db.contacts.create({
    data: { name: formData.get("name") }
  });
  return new Response(null, { 
    status: 302, 
    headers: { Location: "/contacts" } 
  });
}

export default function Contacts({ data }) {
  return (
    <div>
      <h1>Contacts</h1>
      <ul>
        {data.map(c => (
          <li>{c.name}</li>
        ))}
      </ul>
      <form method="post">
        <input name="name" required />
        <button type="submit">Add Contact</button>
      </form>
    </div>
  );
}

Notice the key differences: native Response objects instead of json() helpers, native <form> instead of <Form>, and direct data passing instead of useLoaderData().

The State of Remix 3 Today

As of February 2026, Remix 3 is under heavy active development. Core packages are marked as experimental, and the team has been clear that it is not ready for production use. Key things to watch:

  • Documentation: No official technical docs exist yet. What we know comes from code shown at Remix Jam 2025 and community analysis.
  • API Stability: Specific APIs and architecture are still in flux.
  • Ecosystem: There is no equivalent to the React ecosystem for Remix 3 yet -- no component libraries, no established testing patterns, no third-party integrations.
  • Timeline: The first stable release is targeted for early-to-mid 2026, but no firm date has been committed.

Practical Takeaways

  1. Do not rewrite production apps for Remix 3 today. It is experimental. Use React Router v7 for production work.
  2. Experiment with Remix 3 in side projects. Understanding its model will make you a better web developer regardless of which framework you use day-to-day.
  3. Invest in learning web platform APIs. Whether or not you adopt Remix 3, the trend toward web standards is real and accelerating.
  4. Watch the Custom Events pattern. Remix 3's use of CustomEvent for component communication is an underappreciated pattern that works in any framework.
  5. Keep React skills sharp. React is not dying. It powers an enormous portion of the web and will continue to do so for years. But understanding alternatives makes you more versatile.

The Bigger Picture

Remix 3 is a bold bet. By breaking from React, the Remix team is wagering that the web platform has matured enough to serve as the foundation for a full-stack framework without the intermediary of a virtual DOM library. Whether this bet pays off will depend on execution, ecosystem development, and whether developers are willing to trade the comfort of React's massive ecosystem for the elegance of web-standards-first development.

What is undeniable is that the conversation has shifted. The question is no longer "which React framework should I use?" but rather "do I even need React?" -- and that is a question worth taking seriously in 2026.

Comments