Hotwire vs React: Choosing the Right Frontend Approach for Your Rails App

“Should we use React or Hotwire?” is one of the most common architecture
questions we hear from Rails teams. The honest answer is: it depends on the
feature, not the whole app.

What Hotwire is genuinely great at

Turbo Drive, Turbo Frames, and Turbo Streams handle the majority of what
most web applications need: navigating between pages without full reloads,
updating a section of the page after a form submission, and broadcasting
real-time updates from the server. Stimulus adds just enough JavaScript
behavior — toggling a menu, auto-submitting a search form — without
requiring a build step or a separate API layer.

For CRUD-heavy admin panels, dashboards, and most SaaS product UIs, this
gets you 90% of the interactivity users expect with a fraction of the code
and cognitive overhead of maintaining a separate frontend application.

Where React still earns its place

Some UI patterns are genuinely easier in a client-side framework:

• Complex, deeply nested client-side state (a multi-step visual editor)
• Heavy use of client-side charting or canvas-based interactions
• Offline-first behavior or optimistic UI that needs fine-grained control
• A UI so interaction-heavy that server round-trips would feel sluggish even with Turbo Streams

A pragmatic hybrid approach

You don’t have to pick one framework for the entire application. Many
successful Rails apps use Hotwire for 95% of the product and mount a
focused React component (via a Rails view helper and a JSON API endpoint)
for the one or two screens that genuinely need it — a rich text editor, a
drag-and-drop kanban board, a live collaborative canvas.

This keeps your primary complexity budget low while still giving your most
demanding screens the tooling they need.

How to decide, feature by feature

Ask three questions for each screen:

1. Does this feature need client-side state that outlives a single Turbo Frame update?
2. Would the user-perceived latency of a server round-trip meaningfully hurt the experience?
3. Is there a mature Rails/Hotwire pattern for this already, or would we be fighting the framework?

If you answer “yes” to the first two and “no” to the third, that’s a
reasonable case for a scoped React component. Otherwise, Hotwire will very
likely get you there faster and with less long-term maintenance burden.