Remix 3: Embracing Web Standards Beyond React

Remix 3: What's Changing and Why It Matters

A developer-focused deep dive into Remix 3's principles, architecture, and why it moves beyond React toward web standards.

Ebenezer Don Developer Advocate

For a while, it seemed like Remix had reached a natural conclusion. By late 2024, nearly every feature that distinguished Remix—its loaders, actions, and nested routing—had been integrated into React Router 7. The framework's creators, Ryan Florence and Michael Jackson, even quipped that Remix 2 had become "React Router, the Framework." Many developers anticipated Remix would gradually disappear.

However, in May 2025, the team announced Remix 3, an unexpected and complete rebuild designed to fundamentally rethink web application development. Early previews were showcased at Remix Jam 2025, and while the first stable version is slated for early 2026, the core objectives are already clear: Remix 3 completely breaks free from React and reorients itself around web standards.

This represents a significant leap. The framework now operates directly on the Fetch API, utilizing standard Request and Response objects, rather than Node's proprietary req and res system. This design allows it to run on any JavaScript runtime—Node, Deno, or Bun—without the need for adapters. It continues to support the familiar patterns developers appreciated in Remix 2, but without reliance on React's lifecycle or its virtual DOM. The team describes this as a move toward being "closer to the web itself."

Why the Remix Team Chose to Rebuild in Version 3

When Remix first began, React was a natural foundation. Its component model, rendering flow, and expansive community provided Remix with an immediate advantage. Over time, however, that foundation began to constrain the team's ambitions.

By 2024, the React ecosystem had become increasingly complex. Developers had to navigate new patterns like Server Components, use server and use client boundaries, Suspense, and a proliferation of new hooks. Next.js, the most prominent React framework, continued its rapid evolution, often at the expense of simplicity.

Meanwhile, Remix 2 had become leaner, with most of its core logic migrated into React Router. The additional layer Remix provided on top no longer felt justified for maintenance. The team ultimately decided to stop chasing React's roadmap and instead design a simpler system that would function consistently across all JavaScript runtimes.

This rebuild also signifies a return to the intrinsic strengths of the web. Browsers are inherently designed to handle navigation, forms, and requests. The Fetch API, URL, Request, and Response objects are now universally available on both the server and client. Remix 3 builds directly upon these native features, avoiding extra layers of abstraction. The goal is to shift web development away from rigid "framework rules" and back toward leveraging the platform that already exists.

The Six Principles Guiding Remix 3

The team outlined six core principles that define the direction of Remix 3:

1. Model-first development. Write code that is easily understandable by both humans and tools. Each route's purpose—what data it loads, what actions it performs, and how it integrates into the overall application—should be explicitly clear. This enhances maintainability and simplifies reasoning, whether by a developer or an AI code assistant.
2. Build on web APIs. Directly use standards like Fetch, Request, Response, and FormData. This ensures that a Remix 3 application written for Node can also run on Deno or other JavaScript runtimes without code modifications.
3. Religious about runtime. Avoid build-time "magic." Features should operate at runtime, without requiring a custom bundler or code generator. While TypeScript or JSX can still be used, the code written closely mirrors what is actually executed.
4. Avoid heavy dependencies. Remix 3 aims to minimize its reliance on third-party code. Instead of depending on large frameworks like React or Express, it implements small, focused modules that the team can fully control and evolve.
5. Demand composition. Every component of Remix 3 is designed to function independently. The router, server utilities, and data parsers can each be utilized separately or as part of the complete framework. This modular philosophy echoes projects like TanStack, where each tool is independently useful but works seamlessly in concert.
6. Distribute as one. Despite its internal modularity, Remix 3 will be shipped as a single package. Developers will not need to assemble multiple pieces; the framework will present a unified API.

Collectively, these principles explain the significant divergence of Remix 3. The team's vision is a system that is internally modular and flexible, yet simple and predictable from a user's perspective.

A New Architecture Built on Web Standards

Remix 3's architecture is fundamentally centered on the Fetch API. Every incoming request, whether from a browser, a test, or an edge worker, is a standard Request object. Every response the framework sends back is a Response object.

At the core of this system is a new router named @remix-run/fetch-router. It is type-safe, explicit, and does not rely on file naming conventions. Routes are defined programmatically, often in a routes.ts file, where each route is assigned a name and a path. For example:

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

From this definition, Remix can infer types and generate helpful utilities like routes.books.show.href({ slug: "gatsby" }). This ensures links are type-safe and prevents common errors, while also enabling the router to generate correct URLs for any environment.

The New Rendering Model

The most significant change is that Remix 3 no longer uses React. While you still write JSX, it is processed by a custom component model built specifically for Remix, completely devoid of a virtual DOM. When a change occurs, you update state directly and call this.update() to refresh that specific part of the UI. Events leverage the browser's native event system, rather than React's synthetic one.

This approach makes the rendering model much closer to plain JavaScript. Developers gain clear visibility into what is happening without having to infer hidden framework behavior. The trade-off is that updates require more deliberate action—there's no useState hook to trigger automatic re-renders. However, this also translates to fewer performance surprises and significantly reduced overhead.

To facilitate partial updates, Remix 3 introduces a feature called Frames. A Frame is a defined section of the page that can load and update independently. When a Frame refreshes, the server transmits a small HTML fragment, which Remix then patches into the DOM. This enables streaming updates without additional JavaScript or JSON APIs, an approach similar to HTMX where the server sends HTML instead of JSON, keeping logic server-side while maintaining interactivity.

For instance, a comments section could reside within a Frame. When a user submits a new comment, the server renders updated HTML specifically for that frame and sends it back. The rest of the page remains untouched, providing a client-side interactive feel, but driven by the server and progressively enhanced.

Data Loading and Actions

The loader and action pattern, a defining feature of Remix 2, remains. Each route can export handlers for different HTTP methods. A GET handler fetches data for rendering, while a POST (or PUT, DELETE) handler performs data mutations.

Here’s a simple example:

export const handlers = {
  async GET({ params }) {
    const post = await getPost(params.slug);
    if (!post) return render(<NotFound />, { status: 404 });
    return render(<PostPage post={post} />);
  },
  async POST({ request, params }) {
    const form = await request.formData();
    const comment = form.get("comment");
    await saveComment(params.slug, comment);
    return redirect(routes.posts.show.href({ slug: params.slug }));
  }
};

In this setup, the GET handler executes on the server and renders HTML for the initial page. The POST handler processes a submitted <form>, updates data, and then redirects. Remix subsequently re-runs the necessary loaders to refresh the UI.

This is a key advantage: Remix executes JavaScript on the server but leverages existing browser capabilities on the client side. This makes applications more accessible to parsers, devices with limited JavaScript support, and browsers with JavaScript disabled. The browser handles POST and redirects using standard HTML forms, which functions even without JavaScript.

This pattern ensures app predictability. Data consistently originates from a single source—the loader for that route—and every action leads to a clear revalidation path. No client-side fetching hooks or state management libraries are required.

Error Handling

Error handling in Remix 3 continues the route-based model inherited from Remix 2. Each route can define its own error boundary, ensuring that failures are localized. If a child route fails to load or render, only that specific section displays an error message, while the remainder of the page stays intact.

When a loader throws a Response with an error status, Remix automatically triggers the corresponding error boundary. For example, if a loader throws new Response("Not found", { status: 404 }), Remix will render the Not Found UI for that specific route while keeping parent layouts mounted.

This approach prevents a single broken component from blanking the entire page (a common issue in many SPAs) and helps developers manage network or data errors gracefully.

TypeScript and Developer Experience

Remix 3 is built in TypeScript from the ground up, meaning every route, loader, and action is strongly typed. Route parameters and return types are automatically inferred. For instance, if routes.books.show has a :slug parameter, TypeScript will recognize that params.slug is a string within its handlers. This can be combined with schema validation libraries like Zod to validate form data and API inputs at runtime.

Because Remix avoids code generation, a separate typegen step is unnecessary. The framework infers everything directly from the code you write. This runtime-first philosophy also allows you to run your application directly in ts-node during development, eliminating the need to wait for a full build.

The development workflow is also simplified. The preview demos demonstrate a single remix dev command that launches a local server, watches files, and reloads automatically—no webpack configuration or complex bundler setup required. While Remix 3 is still in preview, you can follow the official blog and GitHub repository for early access and updates.

Deployment and Environment Support

Remix 3's platform independence is one of its most compelling features. Since it's built on the Fetch API, the same application can run on Node, Deno, or Bun with virtually no modifications.

The router processes incoming requests as Request objects and generates Response objects, simplifying deployment to just a few lines of code:

import { createRequestListener } from "@remix-run/serve";
import { router } from "./router";

export default createRequestListener({ router });

This pattern works seamlessly across Node, Appwrite Sites, Netlify, Vercel, or on edge workers. Because the framework does not rely on Node-specific APIs, there is nothing to rewrite when switching platforms.

This also makes Remix 3 easier to scale. You can deploy it as serverless functions, edge workers, or a long-running Node process, depending on your specific needs. The framework deliberately avoids forcing a specific host or vendor, aiming for Remix 3 applications to run anywhere without vendor lock-in.

Trade-offs and What to Expect

Rebuilding a framework from scratch inherently involves trade-offs. Dropping React means losing direct access to its vast ecosystem. Libraries like Material UI or React Query will not integrate directly. Developers will instead rely on plain web components, smaller JavaScript libraries, or future Remix-specific packages.

There's also a learning curve. Without React's hooks or automatic rendering, you will manage updates manually. This concept is simpler but demands a different habit—a shift from "declare and forget" to "update when needed."

Nevertheless, the potential benefits are clear: reduced complexity, less client-side JavaScript, and improved out-of-the-box performance. This approach brings Remix closer to the web's inherent strengths—fast initial loads, resilient forms, and consistent server logic—while retaining the conveniences of a unified framework.

Looking Ahead

Remix 3 is still in preview, yet it already represents one of the most intriguing developments in web technology today. It reflects a broader industry shift in how developers approach the web: moving away from heavy client-side frameworks and back toward simplicity, standards, and server-driven logic.

For teams currently using Remix 2 or React Router 7, nothing will break overnight. These tools remain stable and fully supported. Remix 3 is the evolution, a framework reimagined around what the web already excels at.

As development progresses through 2025 and 2026, the framework will gain polish and comprehensive documentation. Upon reaching a stable release, developers can anticipate a system that feels lighter, easier to deploy, and more aligned with the natural workings of the web.

Remix 3 is not yet complete, but its direction is unmistakable: a profound return to fundamentals, built for a web that doesn't need to be reinvented.