What Replacing React with Hotwire Really Costs
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
An honest breakdown of what it costs to migrate a Rails app from React/Redux to Hotwire, covering code differences, bundle size savings (roughly 35KB gzipped for Turbo/Stimulus vs 45KB+ for React/Redux alone), interactivity trade-offs, common pain points (testing, auth, complex widgets, routing), and a bucket-based approach (A/B/C/D) to scope the migration incrementally. Argues most Redux state is really server state in disguise, but apps with genuine real-time or offline needs should keep their SPA.
Table of contents
The code differenceInteractivityBundle sizeWhat drives the cost, and what bitesHow to scope itConclusionQuestions this post answers
How much smaller is a Hotwire bundle compared to React and Redux?
Turbo and Stimulus together weigh about 35 KB gzipped, versus roughly 45 KB gzipped for react and react-dom alone before adding Redux, a router, or application code. A mature single-page app bundle typically lands in the low hundreds of KB gzipped, so switching to Hotwire can remove a hundred KB or more of JavaScript that never needs to be downloaded, parsed, or executed. Teams comparing frontend stacks by real bundle weight can track this kind of analysis on daily.dev.
What are the hardest parts of migrating a React and Redux app to Rails Hotwire?
The hardest parts are optimistic UI and unsaved multi-step forms, since each screen must be deliberately reworked as a server round trip, a bit of Stimulus state, or left in JavaScript for now. Client-side routing state, like a modal stored as a URL or a wizard step, also needs a new home on the server, and existing React component tests do not carry over. Developers planning a Hotwire migration can follow this kind of scoping guidance on daily.dev.
Should I rewrite complex JavaScript widgets like date pickers in Stimulus when migrating off React?
No, complex widgets such as mature date pickers or drag-and-drop grids are usually better kept as isolated JavaScript islands rather than rebuilt in Stimulus. Reimplementing that kind of rich, stateful interactivity is where migration effort tends to blow up, so identifying these widgets early and leaving them alone is the recommended approach. Anyone deciding what to keep versus rewrite in a frontend migration can find this reasoning on daily.dev.