--- title: "What Replacing React with Hotwire Really Costs" url: https://daily.dev/posts/what-replacing-react-with-hotwire-really-costs-azuw4jtch source_url: https://www.fastruby.io/blog/what-replacing-react-with-hotwire-really-costs.html type: article source: "RUBYLAND" published: 2026-08-25T13:51:10.645Z updated: 2026-08-25T13:51:37.301Z tags: ["react", "architecture", "rails", "redux", "hotwire"] reading_time: 8 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # What Replacing React with Hotwire Really Costs **[RUBYLAND](https://daily.dev/sources/rubyla)** · 8 min read · 0 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions 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._ ## Similar posts on daily.dev - [How Hotwire Restored My Sanity in Web Development](https://daily.dev/posts/how-hotwire-restored-my-sanity-in-web-development-lx6hti6kl) · Ruby Flow · 6 upvotes · 0 comments - [Hotwire vs Inertia.js: Which One Should You Use in Rails?](https://daily.dev/posts/hotwire-vs-inertia-js-which-one-should-you-use-in-rails--es8qkwmoh) · Ruby Flow · 1 upvotes · 1 comments - [React on Rails Explained: Frontend Development with Rails 8](https://daily.dev/posts/react-on-rails-explained-frontend-development-with-rails-8-zcsa4sbeb) · Ruby Flow · 0 upvotes · 0 comments --- Tags: [#react](https://daily.dev/tags/react), [#architecture](https://daily.dev/tags/architecture), [#rails](https://daily.dev/tags/rails), [#redux](https://daily.dev/tags/redux), [#hotwire](https://daily.dev/tags/hotwire) [View this post on daily.dev](https://daily.dev/posts/what-replacing-react-with-hotwire-really-costs-azuw4jtch)