Remix 3 RC: A Full‑Stack Framework That Can Replace React

Remix 3 RC has been released, positioning itself as a full‑stack JavaScript framework that aims to go far beyond routing and server‑side rendering.

The default Remix project now has only one dependency:

{
  "dependencies": {
    "remix": "3.0.0-rc.1"
  }
}

This single remix package contains routing, request handling, database utilities, resource services, a UI runtime, and testing tools, giving the framework a solid claim to be a complete full‑stack solution.

Version clarification

The Remix team published the first candidate version on August 31, version 3.0.0-rc.1. An RC indicates that feature freeze is complete and the focus shifts to bug fixes, security audits, documentation, and early‑user feedback. It is still a pre‑release, so production projects should wait; new projects or internal tools are safer testbeds.

From the Beta on April 30 to this RC, Remix 3 saw over 350 commits. The official changelog lists many changes, but the most notable are highlighted below.

Backend code now supports hot‑module reloading

Front‑end developers are familiar with HMR: changing a component updates the browser while preserving state. Remix 3 extends this experience to the server side. When a server module changes, the development server reloads the relevant code, allowing UI components to update in place without restarting the entire process.

This eliminates the typical split feedback loop where front‑end changes are instantly visible but back‑end changes require a full restart, creating a more seamless development experience.

Integrated database workflow

Many full‑stack frameworks leave database handling to the developer, requiring separate ORM selection, migration tools, and seed scripts. Remix 3’s CLI now includes a built‑in database workflow covering migrations, seed data, status checks, reset, clear, and rollback. Configuration lives in remix.json, from which the database, resources, and tests are read.

Developers can still swap out parts: validation can be replaced with Zod, and the table tool can be switched to Drizzle, so Remix provides defaults without locking every layer.

Remix 3 is not bound to React

Remix 3 introduces its own UI runtime with composable event handling, styling, animation, and built‑in components such as Tabs, Toggle, and context menus. The framework explicitly states that teams wishing to keep React can replace the default rendering middleware with a React‑based implementation.

This clarifies the relationship between Remix and React Router: React Router continues to focus on routing within the React ecosystem, while Remix moves toward a complete application framework with its own UI layer. The choice carries risk because Remix must build a component ecosystem and maintain long‑term support, but the RC already runs and will need further maturation before wide production adoption.

One package does not mean a monolith

Packaging everything into a single dependency reduces the number of installed packages and the surface area of version compatibility, but security still depends on code quality, release processes, and audit results. Remix 3 uses internal composition: routes are mounted via router.mount(), and data validation, tables, and rendering layers remain replaceable, preserving module boundaries.

Resource handling follows the same pattern. JavaScript, CSS, images, fonts, and npm packages are served directly by an unbundled resource server with built‑in preloading. Single‑page applications can reuse the same routing, middleware, controller, and Request/Response handling model.

Web APIs become the common language between modules, reducing the mental overhead for developers and simplifying the conventions that AI‑assisted coding tools need to understand. The Remix team emphasizes that the code should rely on web standards, types, and ordinary JavaScript scopes.

Is it worth using now?

Creating a new project is a single command: npx remix@next new my-remix-app The author would recommend Remix 3 RC to three groups: front‑end teams starting new projects (to save on technology selection), teams building internal tools (to evaluate the database workflow and HMR), and developers who frequently use AI coding assistants (to test whether the Web API and single‑dependency approach improve generated code stability).

Teams with existing Remix 2 or React Router production projects should wait for the stable release and migration documentation, as the official docs are still being completed and security audits remain pending. After the official October 2 launch, migration costs can be assessed more concretely.

Remix 3’s direction is clear: it provides a ready‑to‑use full‑stack combination while allowing any unsuitable layer to be swapped out. Whether this will attract front‑end developers again depends on the stability of the final release and the growth of its ecosystem. At the RC stage, Remix already offers a more concrete answer than simply being “another React meta‑framework.”