React and Remix Choose Different Futures

Brian Cantrill’s talk platform as a reflection of values ​​gave me a lens I didn’t know I needed. He argued that when platforms differ, it is rarely about technical merit. It’s about a misalignment of values. The things that matter most to one community rank differently for another community.

I attended Remix Jam two weeks ago, then spent last week watching React Conf 2025 videos. I’ve spent the last decade shipping production code on React and the last two years on Remix.

Now both ecosystems are changing, and what appeared to be separate approaches have become incompatible approaches.

Technical announcements at React Conf were incremental: React 19.2 API, View transitions experiment, the compiler becoming more sophisticated. The message was clear: React is listening to the community while embracing complexity on your behalf. Stability, integrity, efficiency: these are the values.

The Remix team also announced something else entirely: they’re parting ways with React. mental model change introduced by use client And the implementation complexity of the server components forced a choice. And Remix 3 chose simplicity. Remix 2 users have to pay a price; There is no upgrade path.

That choice to sacrifice stability for simplicity makes clear what was already true: these values ​​cannot coexist.

The Value of Feedback: Complexity as Capacity

React’s stated goal is to “raise the bar of responsive user experience”. At React Conf 2025, the team demonstrated what this means in practice. If it provides a better experience for end users they will accept a tremendous amount of complexity on the part of developers.

The React compiler is the clearest example of this. It analyzes your code, breaks components into smaller pieces of logic, and automatically optimizes rendering. In Meta’s Quest Store app, they saw 12% faster load times and interactions that were twice as fast, even though the app was already hand-optimized. The compiler is not replacing developer skills; It is handling complexity that would be unrealistic to maintain manually. Joe Savona explained the challenge: In context-based apps where “every component has to be updated” the compiler now leaves much of that work to it automatically.

This is the value proposition of React: Stability (the compiler works with existing code), creativity (It integrates with concurrent rendering, suspense, transitions), and Capacity (This unlocks performance that manual optimization can’t reach). When the team talked about their multi-year exploration into incremental computation, they weren’t apologizing for complexity. He was explaining the cost of raising that bar.

The React team knows this makes React complex. But the bet is clear: React falls on the sword of complexity so developers don’t have to. This is commendable, but it also asks developers to rely on the invisible machinery of React more than ever.

Per-value of Remix: Simplicity as liberation

The Remix team remembers when React was a composable rendering library with just a few primitives. At Remix Jam, Ryan Florence demonstrates what simplicity looks like when it becomes your organizing principle: more detectable than implicit, explicit more than automatic.

The clearest example is this.update()When Ryan created a live drum machine on stage, every position change was manual: “In this code, the only time anything gets updated is when I told it to,” No automated response graphs, no hidden subscriptions, no debugging why something re-renders unexpectedly, If you’re wondering why a component was updated, “It’s because you told it to be somewhere,”

This clarity extends to the Remix 3’s design. Uses event handling on A property with native DOM events that bubble through the normal DOM. Abortion Controller (this.signal) Cleaning the wire clearly. Context does not trigger re-render. You set it, the component reads it, and you call this.update() When you want things to change.

After demonstrating the drum machine, Ryan explained the philosophy: “We’re pursuing the idea that you build things together, change the values, and everything does what it’s supposed to do. But my experience is that it’s difficult to set up, and once it’s set up, all of a sudden when something unexpected happens, you have to figure it out.”

When Michael Jackson demonstrated server rendering component, he showed how it uses plain HTML as its wire format. React Server components solve real problems, but Remix believes it can solve them more easily by leaning on the web platform.

This is the value proposition of Remix: Simplicity (Explicitly control when things are updated), web platform alignment (standard events, standard streams, cross-runtime compatibility), and debuggability (Trace every update back to a specific this.update() call out). The team isn’t rejecting React’s goal of raising the UX bar, but they are rejecting the complexity tax React has to accept to achieve it.

Web Platform: Inevitable or Chosen?

There is an irony in using Cantrill’s framework to analyze Remix’s break from React: the Remix team does not see its web platform commitment as a choice of values ​​at all. They believe they are simply skating to where the puck is going. Each framework will eventually adopt web platform APIs. it’s only a matter of time.

But Cantrill’s conversation suggests this is a clear value option, not an inevitable destination. He lamented Node.js adopting a web platform API to make it easier for browser developers to work with server-side JavaScript, choosing approachability over rigor. The practitioners who brought those APIs to Node were the ones who were driving their values: robustness, debuggability, operational correctness. For Cantrill, aligning with the web platform meant sacrificing engineering rigor for developer convenience.

Remix 3 is building itself entirely on the same web platform APIs. Stream, fetch, file API, each platform dependency behaves the same in browser, bun, deno and node. Ryan and Michael demonstrated this throughout the Remix Jam: standard HTML responses, native DOM events, cross-runtime compatibility. The React Web Platform also respects APIs, but treats them as a foundation to build upon. Remix 3 treats them as destinations. This has always had a remix value, which is evident in Remixes 1 and 2, but Remix 3 makes it complete.

And I love the remix for it.

I’m a big fan of the open web, but I’m not convinced that every server framework will or should be perfectly aligned with the web platform. Browsers and servers live under different constraints that force different tradeoffs. The goal is not to erase the seam between them, but to make it visible and intentional. Remix 2 handles this tension beautifully. However, this is a result of the interest in highlighting the platform, not the inherent result of engaging with it.

Remix 2 is dead. Long live the react-router!

Despite Remix having one of the best upgrade policies in the industry with future flagships, there will be no migration path from Remix 2 to Remix 3. The changes are very fundamental. At the Remix Jam, Michael Jackson clearly stated: “We’ve been working on React Router for a decade… A lot of people have built on React Router. Shopify built on React Router… We’re just not going to give up on that thing.” Remix 2 users get a maintained development path as of React-Router v7. But Remix 3 is calling off the divorce and moving in a new direction.

When simplicity becomes the organizing principle, sustainability becomes non-negotiable. New on Assets cannot co-exist with React’s legacy event system. clear this.update The API completely replaces React’s hooks. Breaking backward compatibility isn’t collateral damage, that’s the point. This opens up design space for tricks like overloading this (giving components an optional second parameter without relying on argument order), which seems simple because it relies on existing capabilities of JavaScript.

Alpha is expected by the end of the year, with a consolidated package to follow in 2026. But the caveat is clear: Remix 3 isn’t ready for production any time soon. Everything is new and subject to change. Meanwhile, we have react-router.

open questions

Relying on events as the communication backbone is smart, but it reminds me of complex Backbone.js apps that relied on a shared event bus to communicate across all components. This worked for a while, but at a certain level of complexity, it became difficult for new developers to get up to speed on existing projects. Remix’s clarity and TypeScript support should help. But will this be enough to solve the challenges we could not solve in 2010?

this.update() The mental model makes it easier to understand compared to React’s hook system. But clearer rendering means more functional code. AbortControllers require you to manually perform wire cleanup. The compromise is clear: you write more, but understand more. Whether that’s liberation or simply transferred complexity depends on your team and your codebase.

The story of Remix 2 and React-Router shows that Ryan and Michael are no strangers to leaning toward what works. This is definitely one of their strengths, but it’s hard for larger organizations to build on top of a changing platform. How much will change before Remix 3 is installed?

to be in deviation

Cantrill ended his talk with a warning: “Elections don’t solve differences in values. You can get as many votes as you want. If you’re not really changing people’s minds, not changing their values, you’re not really solving anything.”

The react-router fork exists because the Remix team knows that values ​​don’t change overnight. This is a safer path for those who need the stability of Remix 2 while Remix 3 proves itself. This division acknowledges reality: production software does not adopt new frameworks on sight alone. Teams will choose different options based on different values. Some people will stick with React and embrace the sophistication of the compiler. Some will move quickly to Remix 3, betting that the Simplicity migration is worth the cost and uncertainty.

Both paths are valid. but they are legit for different valuesWhen the framework clearly prioritizes what’s most important, teams can’t avoid making choices, Not based on features or performance benchmarks, but based on what type of complexity they are willing to accept and what type of control they need to maintain, This is not a technical decision, This is a values ​​decision,

The React ecosystem now has two incompatible visions of its future. Cantril’s framework helps us see why this is okay, even if it is inconvenient. Choose your prices, then choose your equipment.



<a href

Leave a Comment