The short answer
For most Rails apps in 2026, ship Hotwire. The 90/10 rule applies: 90% of features work great with Turbo Frames and Stimulus, leaving 10% that genuinely need React. Pick React for the SPA-shaped slice only — collaborative editors, complex real-time dashboards, Notion-like surfaces. Don't pick React for CRUD just because the team knows it.
We've shipped both at production scale. The ZenHQ grocery delivery platform uses React for the customer-facing checkout (Paysafe 3DS plus a tight UX that React's component model serves cleanly). Internal admin tools and customer dashboards across multiple clients are Rails+Hotwire because the work is fundamentally form-and-table-shaped. Both are correct for their context. The trap is picking React by default because it's "modern."
Watch first: DHH on the Rails 8 + Hotwire vision
DHH's Rails World 2024 opening keynote is the best 45-minute investment for understanding why Hotwire's design exists at all. He frames the bet 37signals is making: that ERB + Turbo + Stimulus is enough to build apps as ambitious as Basecamp, HEY, and ONCE — without the SPA architectural tax.
The two architectures at a glance
| Dimension | Rails + Hotwire | Rails API + React |
|---|---|---|
| Rendering | Server-side ERB + partial replacement | Client-side React + JSON API |
| Build pipeline | None required (importmap or Propshaft) | Vite or Webpack, plus Node version drift |
| JS bundle size | ~40 KB (Turbo + Stimulus) | ~150–400 KB (React + Router + state lib) |
| Team needed | Rails developers | Rails + React (or 1 full-stack) |
| SEO | Indexed by default (server-rendered) | Needs SSR via Next.js or similar |
| Real-time updates | Turbo Streams over WebSocket | WebSocket or polling, custom state mgmt |
| Complex client state (drag/drop, canvas) | Stimulus controllers, gets awkward at scale | Native model, clean |
| Time to ship a CRUD feature | Hours | Days (controller + serializer + API consumer + form + state) |
The pattern is unambiguous: Hotwire wins on speed-of-shipping and operational simplicity. React wins on raw client-side capability and team-portability when the team is already React-native. Most arguments about "which is better" boil down to which side of that trade-off the author values more — not a universal answer. The official Hotwire docs and the React docs are both worth reading from the framing perspective — each project is honest about what it optimises for.
The 5-question decision framework
1. Is your app fundamentally form-and-table-shaped, or canvas-shaped?
Most B2B SaaS, marketplaces, dashboards, admin tools, and CRUD apps are form-and-table-shaped. Users submit data, see it back, edit it, filter it. Hotwire was designed for this shape and is hard to beat.
Canvas-shaped apps are different — collaborative document editing, design tools, visual programming, real-time multiplayer. State is deep, mutations are frequent, the UI must react instantly to local interactions. React (or a similar reactive framework) earns its keep here because Stimulus controllers stop scaling cleanly past a certain interaction complexity.
Be honest about which shape your app is. "We might add a canvas feature eventually" is not a reason to start in React.
2. What's your team's primary fluency?
If you have senior Rails developers and you're hiring more, Hotwire is the right call — one fewer skill to hire for. If you have a React-native team that ships React features every week, forcing them into ERB will slow you down for 6 months while they relearn server-rendered patterns.
Greenfield team forming now: hire Rails-Hotwire. The pool is more concentrated and the productivity ceiling is higher per engineer because there's less infrastructure to maintain.
3. How important is SEO and first-paint speed?
Server-rendered HTML wins both SEO and first-paint without effort. React requires SSR via Next.js (or Inertia bridging) to match. If you're building anything search-driven — a marketplace, a content platform, a public-facing SaaS — Hotwire saves you the SSR engineering cost. Our modern frontend architecture guide walks through when SSR matters and what it costs.
4. Do you need real-time collaboration with cursors and presence?
Hotwire's Turbo Streams handle broadcast updates ("new comment appeared" type events) cleanly. They do not handle CRDT-style collaborative editing with merge resolution. If you're building Figma, Notion-style collaborative docs, or live multiplayer, you'll need React (or another reactive framework) plus a CRDT library plus a presence system. Hotwire isn't the wrong tool because it's missing those features — it's the wrong tool because that's not what it's optimised for.
5. What's the 24-month team plan?
Solo founder or 2-3 person team: Hotwire, no debate. The "one-person framework" claim is real — DHH's original post on the concept isn't marketing copy, it's a workable architectural stance.
Team scaling to 20+ engineers across distinct frontend and backend specialties: the React side becomes more defensible because you can hire specialists into the frontend who never touch Rails. Trade-off: more coordination overhead, more glue code between frontend and backend.
Where Hotwire clearly wins
- Admin panels and internal tools. Form, table, filter, action. Hotwire ships this faster than any React stack.
- CRUD-heavy B2B SaaS dashboards. Customer-facing tools where users mostly view-and-edit records.
- Marketplaces and content platforms. SEO matters, every page should be server-rendered.
- Solo founders and small teams. One developer ships an entire app without an SPA toolchain.
- Apps where Rails-side caching dominates performance. Russian-doll caching plus Turbo is genuinely faster than React-fetches-JSON for most read-heavy pages.
- Anything you'd build in Phoenix LiveView, Laravel Livewire, or HTMX. Same architectural pattern, Hotwire is the Rails-native expression.
The Hotwire and Turbo deep dive covers the implementation patterns — Turbo Frames for partial updates, Turbo Streams for server-pushed changes, Stimulus controllers for client-side interactivity.
Where React clearly wins
- Collaborative editors (Figma, Notion-style, code editors with real-time cursors).
- Complex client-side state machines — drag/drop with multi-select, wizard flows with deep validation, canvas tools.
- Offline-first apps with local-first sync (Hotwire assumes server connectivity).
- Apps with significant existing React engineering investment. Throwing that away for ideological purity is wasteful.
- Apps needing the React Native code-sharing path — React Native bridges component reuse with web; Stimulus does not.
- Apps where the frontend team is independent from the backend team. API contract becomes the natural seam; both sides can move independently.
Our Rails API + React full-stack architecture piece covers the patterns that work when this is the right call.
The hybrid pattern most teams converge on
Both extremes — pure Hotwire and pure React-SPA — are correct in narrow cases. The middle ground that wins for most production Rails apps:
- Rails + Hotwire for the app shell. Navigation, lists, forms, admin, settings, auth flows — all server-rendered.
- React mounted as an "island" on specific complex slices. A spreadsheet editor inside an otherwise-Hotwire page. A canvas builder inside an admin panel. A live dashboard widget. React owns the complex bit; Hotwire owns everything around it.
- One Rails app, one repo, one deploy. No microservices, no separate frontend deploy pipeline. The React island ships as part of the Rails app's asset bundle.
This is what we shipped for ZenHQ (Hotwire admin shell, React checkout island) and what most successful Rails+JS apps look like internally. Avoids the worst failure modes of both pure approaches.
Migration paths between the two
React-everywhere → Rails+Hotwire: usually triggered by a small team realising they're spending 50% of engineering hours on the JS-backend glue. Typical path: build new features in Hotwire, leave existing React surfaces alone, retire React pages opportunistically. Allow 6–12 months for a meaningful migration; full rewrites are usually wrong.
Hotwire → React for a specific slice: extract one page into a React island when interactivity exceeds Stimulus's clean ceiling. Don't rewrite the whole frontend; just add React to that page's asset bundle. Faster path with smaller risk.
Full rewrites between them: almost always wrong. The team is the bigger constraint than the framework. Rewrites take 12–18 months and rarely deliver the productivity gains promised.
FAQ: Hotwire vs React decisions
Can Hotwire really replace React for a complex SaaS?
Yes for most SaaS shapes — B2B dashboards, CRUD-heavy admin tools, marketplaces. No for genuinely SPA-shaped products like collaborative editors. The honest answer depends on what your app actually does, not the category label.
What about Vue, Svelte, or Solid?
The trade-off is identical to React's. Smaller communities, similar architectural commitment. If you're picking a JS framework over Hotwire, React wins on hiring pool and ecosystem unless you have a specific reason.
How does Turbo Drive handle the "back button" UX?
Correctly. Turbo Drive intercepts link clicks, fetches the new page over fetch(), swaps the body, manages browser history. Back/forward work as expected. The 2018-era complaints about Turbolinks-style breakage are largely fixed in Turbo 8+.
Do we still need a JS-build pipeline with Hotwire?
No, if you use importmap (Rails 7+) or Propshaft (Rails 8). Yes, if you want TypeScript or to import npm packages that aren't ESM-ready. For most Hotwire+Stimulus apps, importmap is enough — no Vite, no Node, no build step.
Can we use Hotwire and React in the same app?
Yes, this is the hybrid pattern we recommend. Mount React on specific routes or DOM elements; the rest of the app stays Hotwire. The asset pipeline handles both. Gems like Turbo Mount make the integration cleaner if you go this route.
How we can help
At TechVinta, we've shipped Rails+Hotwire admin tools, Rails+React production apps, and the hybrid pattern in between — including the React-heavy ZenHQ frontend and a dozen Hotwire-only internal tools. We don't have an ideological position on which one wins. We pick based on what the app actually needs to do, who's going to maintain it, and how fast you need to ship.
Planning a Rails app and stuck on the frontend decision? Talk to our frontend team, or get a free project estimate — we'll review your app shape, team fluency, and roadmap and propose a stack within 48 hours.
