Overreacting – from React to Hotwire

We migrated from React to Rails without rewriting everything. Kept the SPA running, built new features in Hotwire. One Rails dev now delivers what took a frontend-backend duo. I’ll share our hybrid migration strategy, real code patterns, and how to decide if this makes sense for you.

React in 2020 was the obvious choice. Hotwire didn’t exist. Our team needed to build SafariPortal, a complex travel itinerary builder for high-end travel agents. We made the smart, defensible decision that any experienced team would make.

Three years later, that smart decision was strangling us.

The Problem Everyone Faces (But Nobody Talks About)

Here’s what the conference circuit won’t tell you: sometimes your React app doesn’t fail spectacularly – it just slowly, quietly becomes a productivity vampire. Redux actions for every state mutation. Backend developers are waiting on frontend developers, waiting on API contracts. Pull requests that touch seven files to add one form field. The kind of complexity that looks professional on architecture diagrams but murders your velocity in production. By 2024, we faced an impossible timeline: transform SafariPortal from a simple itinerary builder into a full-cycle travel CRM. Four major modules – Task Manager, Contact Management, Financials, and Form Builder – in twelve months. With our existing team. Using our existing React architecture.

While the JavaScript world debated whether to migrate from React to Next.js to Remix to whatever’s launching next week, we did something radical: we went backwards. We started building new features in Rails + Hotwire while keeping our battle-tested React app humming along in production.

No big-bang rewrites, no developer trauma, no user disruption. Just pragmatic coexistence while we proved Hotwire could deliver. And here’s what nobody tells you about “going backwards”: sometimes it’s the fastest way forward.