![]() |
VOOZH | about |
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.
👁 ImageIt’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?
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.
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.”
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.
| React Router v7 | Remix v3 | n8n Output |
|---|---|---|
| Based on | React | Preact fork |
| Stability | Stable, production-ready | Experimental, no official release |
| Mental model | Declarative (Hooks, components) | Imperative (this.update(), closures) |
| Ecosystem | Full React ecosystem | New, limited |
| Migration from v2 | Smooth upgrade path | Complete rewrite required |
| Who it’s for | Existing Remix users | Early adopters, experimenters |
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.
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.
props → native browser eventsRather than passing data down a component tree, the new model encourages CustomEvent for communication. A child dispatches an event; a parent listens for it.
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.
The Remix team outlined four core principles guiding v3’s development. Three are straightforward; one has become a lightning rod for criticism.
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.
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.
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 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.
It depends on what “Remix” means to you.
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.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
We built the same app in TanStack Start RSC and Next.js RSC. TanStack shipped 40% less JS and built 4x faster — but Next.js is still the safer production bet.
From RSC vulnerabilities and the Vercel breach to TypeScript 7.0 Beta and AI agents — the nine frontend storylines that defined H1 2026, ranked.
AI tools generate working React code fast, but miss race conditions, empty states, debouncing, and accessibility. Here’s how to catch bugs before production.
Learn how to use Gemini CLI subagents to delegate frontend, backend, testing, and docs tasks to specialized agents with guardrails and clear ownership.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now