Shopify Remix: How Remix 3 Threatens App Stability
Why Shopify app developers should care about Remix 3, React Router v7 changes, and the need for clear naming and…
📖 Practical Remix Implementation Guides
Comprehensive guides covering Remix patterns, optimization techniques, and developer shortcuts. Plus code snippets and prompts to speed up your workflow.
I develop in the Shopify app ecosystem. If you build Shopify apps today, you are building on Remix. Or more precisely, you are building on React Router v7, which is what Remix effectively became after being merged into React Router.
That alone already requires explanation, and that is part of the problem.
Recently, there has been growing noise around something being called “Remix 3”. Articles, conference talks, and social media threads describe it as revolutionary, a clean break from React, a new reactivity model, HTML over the wire, explicit updates, and a return to web fundamentals. It sounds exciting. It also sounds terrifying if you are maintaining real production software.
As someone actively building Shopify apps, this situation is deeply confusing and increasingly frustrating.
Shopify uses Remix, but which Remix?
Shopify officially chose Remix as its app framework. Developers are encouraged to use it. Tooling, documentation, authentication helpers, and templates are all built around it.
But the Remix Shopify uses today is no longer really “Remix” in the way most people understand it. The original Remix framework was merged into React Router, and modern Shopify apps now run on React Router v7 in framework mode.
This means that as a Shopify developer, you are already living through a rewrite you did not ask for. React Router v7 is not a small evolution from v6. It introduced a new architecture, new server adapters, new configuration patterns, and new mental models. Shopify developers accepted this because it was presented as the stable future.
Now, before that future has even settled, we are being told that Remix itself may abandon React entirely.
A new framework, the same name, and no clear boundaries
The emerging narrative around Remix 3 is not about an incremental update. It is about throwing away React, hooks, the virtual DOM, implicit reactivity, and even file based routing in favor of a custom runtime with explicit updates and HTML driven rendering.
That is not Remix v2 plus improvements. That is a completely different framework.
And yet it is being discussed under the same name.
For developers, this creates real anxiety. When the framework you are using shares a name with an experimental rewrite, it becomes unclear what is stable, what is transitional, and what might be abandoned. Even if no rewrite is required, the perception of instability alone is damaging.
The problem is not experimentation, it is messaging
Experimentation is healthy. The web ecosystem needs people questioning complexity, React’s growing surface area, and the cost of abstraction. The ideas behind the experimental Remix are interesting and worth exploring.
The issue is that this experimentation is happening while Remix is actively used as a foundation by large ecosystems like Shopify.
When developers hear “Remix is moving away from React” without a clear, official distinction between the stable production stack and the experimental one, they naturally fear obsolescence. They fear rewriting apps. They fear betting on the wrong foundation.
That fear is not irrational. It is a direct result of unclear communication.
Developers need boring stability, not constant reinvention
Most developers are not framework hobbyists. We are building products, businesses, and integrations that need to work for years.
Shopify app developers especially operate in a high risk environment. Platform changes already require constant maintenance. Adding framework uncertainty on top of that increases cognitive load and erodes trust.
React Router v7 was already a significant shift. Promising another paradigm shift before the current one has fully stabilized feels exhausting, not exciting.
What would help
The solution is not to stop experimenting. It is to be explicit.
Clear naming boundaries would help. Clear statements about long term support would help. Clear separation between production frameworks and research projects would help.
Most importantly, developers need reassurance that the stack they are building on today is not a dead end.
Final thoughts
I am not opposed to a new Remix. I am opposed to ambiguity.
If a new framework is coming, call it what it is. Treat it as new. Let it earn adoption on its own merits.
For those of us building on Shopify today, we need to know one thing above all else.
That our work is not disposable.
Right now, that confidence is being tested.