When you collect quotes from three agencies for a website or web app renewal, different names appear in the technology stack section. One company proposes “Next.js,” another “Astro,” and a third “Remix.” Since all of them are proven frameworks, clients have little basis to compare them side by side. Ultimately, decisions end up being made on “price and the impression left by the account representative.”
That decision became slightly more complicated this year, because Remix dropped React in version 3. When a framework rebuilds its underlying foundations from scratch while retaining its popularity, it prompts clients to ask: “Will the technology we choose today still exist in the same shape five years from now when we need continuous modifications?”
What Remix 3 left behind
Remix had earned acclaim as a full-stack framework built on top of React. The version 3 beta preview removes that premise entirely. It has been rebuilt from scratch into an architecture that does not use React, does not use a virtual DOM, and does not rely on implicit build-time transformations (Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — InfoQ).
In their place are Web standards. Server-side input and output handle standard Fetch API Request / Response rather than Node-specific req / res. The UI side utilizes a forked Preact, with components sitting on fundamental Web platform primitives like EventTarget.
The practical payoff is the outcome: the exact same code runs across Node 22, Deno, Bun, and edge runtimes. Because it does not depend on Node-specific APIs, rewrites are unnecessary when changing execution environments. For companies that review their hosting providers every few years, this characteristic translates directly into cost savings.
The other factor is authoring ergonomics. React hook rules, dependency arrays, understanding re-renders—these served simultaneously as learning overhead and breeding grounds for bugs. Version 3 returns to normal JavaScript control flow. From the perspective of developer productivity discussions, it is a welcomed change.
Why “we build with React” is no longer the complete answer
Now let us shift to the client's perspective. Frankly speaking, the technical merits and drawbacks of Remix 3 are not a primary concern for most clients. What matters is a different aspect.
React was long the “safe choice.” Hiring talent was easy, libraries were abundant, and someone would still be able to maintain it five years later. On the strength of this reassurance, teams could skip deep discussions around technology selection. However, a prominent framework built on React decided to step away from React. This reality slightly shakes the very foundation of that safety.
Do not misunderstand: this is not about React coming to an end. Its hiring pool has not shrunk at all. What has changed is that the shortcut of “choosing React means not having to think about technology selection” no longer works. When generational shifts in frameworks occur, clients must confirm at the time of ordering which side their site will be left on.
How to evaluate a tech stack from a client perspective is outlined in Tech stack evaluation for small-scale projects. Reading it alongside this will clarify that what happened here is not an isolated anomaly, but part of a recurring cycle.
Where are existing Remix 2 projects headed?
For companies that already operate sites or apps built with Remix, there are concrete ramifications.
Migrating from Remix 2 to 3 is not a straightforward path. Rather than a routine version upgrade, the workload resembles migrating to an entirely different framework. The practical alternative presented by the Remix team is React Router 7. It is positioned to maintain compatibility while preserving React, carrying forward the features that gave Remix its value.
In other words, companies running production Remix 2 apps have two paths: align with React Router 7 to remain in the React ecosystem, or treat a substantial rewrite to Remix 3 as an investment. The former is cheaper, but does not yield the benefits of Remix 3.
The deciding factor is how much you plan to modify that app going forward. If it requires only minor tweaks a few times a year, aligning with React Router 7 to extend its lifespan is more rational. Conversely, if you plan continuous feature additions, the compounding difference in developer experience justifies the investment of a rebuild. It is best approached not as a matter of framework freshness, but as a decision driven by future modification frequency.
Three questions to ask when reviewing estimates
Clients do not need to evaluate the internal mechanics of a framework. Instead, ask the proposing company the following three questions. The specificity of their answers will reveal whether the proposal is the product of deliberate evaluation or merely of habit.
First: “Have past major version upgrades of that framework introduced breaking changes?” It is entirely fine if they have. A company that claims “no, not really” despite their existence is simply not keeping up.
Second: “Can we request modifications with this exact architecture five years from now? If not, what will happen?” Whether a discussion of migration paths emerges here is the critical dividing line. In cases like Remix, the official team may provide a designated destination.
Third: “Which of this project's requirements led to choosing that architecture?” “Because our team is familiar with it” is a perfectly valid reason. In fact, having that concealed is far worse. Proposals filled with technology names untethered to project requirements often undergo arbitrary architectural shifts later on.
Handoffs and maintenance considerations were also covered in Taking over legacy corporate websites. In scenarios where a company other than the original creator handles modifications, framework choices manifest directly as cost.
For most corporate websites, this is not directly relevant
To be frank, there are not many projects where this development has a direct bearing. For a standard corporate website consisting of company information, service overviews, and announcements, there is no need to introduce a full-stack framework in the first place. Static site generation is more than sufficient. This decision criteria is exactly as described in Building corporate website foundations with Astro 7.
Remix 3 matters for projects with user logins, data mutations, and business operations running directly through the application: member portals, reservation and application systems, and internal operational dashboards. If you plan to outsource development in this tier, you should avoid signing off on technology selection with a hands-off “we'll leave it to you.”
Is the rationale explained in the proposal's technology section?
The next time you receive an estimate for a website or web app, check whether the technology architecture section explains the rationale behind why it was chosen. If it is not written, ask. Doing just that will lower the probability of being told five years from now: “We cannot make modifications with this architecture.”
Whether you want to consult on everything from renewal requirements to technical architecture, or assess how maintainable an existing site will be going forward, GleamHub offers consultations for website development and renewals. Because the optimal setup varies depending on your requirements, we provide customized quotes. Please reach out to us via Contact Us.
