Hotwire vs. React: A Guide for the "One-Person Framework"

#rails #react #hotwire #spa

The Default Choice

For the last five years, the "Standard Web Stack" has been undeniable:
Backend API (Rails/Node) + SPA Frontend (React/Vue).

It is the architecture taught in bootcamps. It is the architecture demanded by recruiters. And for a long time, if you wanted a "modern" feeling application—no page reloads, snappy transitions, real-time updates—it was the only way.

But it comes with a cost. I call it The React Tax.

With the maturity of Rails 7 (and now Rails 8) and Hotwire, that tax is no longer mandatory. Here is why I believe Hotwire is the superior choice for 95% of Rails projects.

The Problem: Two Apps, One Product

When you choose React, you aren't building "an app." You are building two apps.

The Backend: Dealing with serialization, JWTs, CORS, and versioning.
The Frontend: Dealing with route management, global state (Redux/Context), effect hooks, and package.json hell.

Suddenly, a simple feature like "Rename a Project" requires:

Frontend: Update UI state optimistically.
Frontend: Dispatch API call.
Backend: Handle auth.
Backend: Update DB.
Backend: Serialize JSON response.
Frontend: Handle success/error.
Frontend: Re-sync local state.

With Hotwire, the flow is:

Controller: Update DB.
View: Render HTML.

1. The "Single Source of Truth" Myth

The hardest problem in Computer Science is naming things. The second hardest is Cache Invalidation.

When you duplicate your database state into a Redux store or React Query cache, you are inviting bugs. Is the user list stale? Did the socket update the count? Why does the UI say "Premium" but the API returned 403?

Hotwire rejects this premise.
With Turbo, the server is the single source of truth. When data changes, you don't update a client-side JSON cache; you simply replace the HTML chunk on the screen with fresh HTML from the server.

You eliminate an entire class of "State desync" bugs because you have no client-side state.

2. Velocity: The "One Person Framework"

Rails 8 is pushing the concept of the "One Person Framework." The idea is that a single developer should be able to build a startup that used to require a team of 5.

If you are a solo dev or a small team using React, you are spending 50% of your time managing the glue between your backend and frontend.

With Hotwire (Turbo Drive + Turbo Frames + Stimulus), you stay in Ruby/ERB land for 90% of the work. You write standard Rails views. You get SPA-speed navigation for free via Turbo Drive. You get dynamic partial updates via Frames.

The Context Switch Cost:

React: Switch from Ruby to JS. Switch from ERB to JSX. Switch from RSpec to Jest.
Hotwire: Stay in the flow.

3. "But React feels better"

This was true in 2016. It is not true today.

Turbo Drive (which intercepts link clicks and form submissions) makes a standard Rails app feel instant. It merges the <head> and replaces the <body> without a full browser reload.

Need real-time? Turbo Streams over ActionCable allows you to broadcast updates to millions of users with a few lines of Ruby.

# app/models/message.rb
after_create_commit { broadcast_append_to "chat_room" }

That one line creates a WebSocket connection that appends the new message to the DOM of every active user. Doing this in React requires setting up a socket context, listeners, state reducers, and safety checks.

When SHOULD you use React?

I am not a React hater. It is an incredible piece of engineering. You should use React (or Vue/Svelte) if:

You are building a high-fidelity tool: e.g., Figma, an in-browser video editor, or a complex drag-and-drop Trello clone.
You need "Offline First": If the app must function 100% without an internet connection (PWA with heavy local sync).
Your API serves multiple clients: If you have a Mobile App, a Web App, and a Desktop App that all need the exact same API, maybe a decoupled frontend makes sense (though native apps are moving to Server-Driven UI too!).