Rails and React in 2026: Hotwire, Inertia, or a separate frontend?

“Should we use React or Hotwire?” is the question we get most from teams starting a Rails product. It’s usually asked as if one answer is correct. It isn’t. There are three good options, and each one is the right call for a different kind of product and team.

This is the framework we actually use on projects. It’s opinionated — that’s the point.

The three options

1. Hotwire (Turbo + Stimulus). Rails renders HTML on the server. Turbo makes navigation and form submissions feel like a single-page app by swapping HTML instead of reloading the page, and Turbo Streams push partial updates over WebSockets. Stimulus adds small bits of JavaScript behavior. This is the Rails default.

2. Inertia.js with React. Rails keeps routing, controllers, auth and validation. Instead of rendering ERB, a controller renders a React page component and passes it props. No API layer, no client-side router, no separate auth — just React as the view layer. The inertia_rails gem is the Rails adapter.

3. A separate frontend. Rails becomes a JSON API (or GraphQL). A separate React app — usually Next.js these days — handles routing, rendering and the user interface, and is often deployed on its own.

The questions that decide it

How interactive is the core of the product?

Be honest about the core screens, not the one fancy widget.

• Mostly forms, lists, dashboards, CRUD with a few live updates? That’s most B2B software, and Hotwire handles it beautifully.
• A few genuinely rich screens — a drag-and-drop planner, a spreadsheet-like grid, a canvas editor? Hotwire for the app, React for those screens (mounted as islands) is often the sweet spot.
• The whole product is the rich interaction — a design tool, a complex editor, an app that works offline? You want React, either through Inertia or a separate frontend.

Who is on the team?

This matters more than any technical argument.

• A team of Rails developers will ship faster with Hotwire, and keep shipping faster as the app grows.
• A team with strong React developers and a Rails backend will be happiest with Inertia — they keep their React skills and component libraries, and skip building an API.
• Separate frontend and backend teams, each with their own release schedule, fit a separate frontend better.

Will anything else consume the API?

If a mobile app, partners or customers need an API anyway, a separate frontend on top of that same API stops being extra work and starts being reuse. If the only consumer is your own web UI, building and versioning an API is cost with no benefit — that’s where Hotwire and Inertia shine.

How much do SEO and first load matter?

Hotwire and Inertia both serve real HTML from the server (Inertia via server-side rendering if you turn it on). A separate frontend can do this too — it’s what Next.js is good at — but now you run and pay for a second server. For a marketing-heavy product with lots of public pages, that can be worth it. For an app behind a login, it rarely is.

The trade-offs nobody puts on the slide

Hotwire

• Good: one codebase, one language for most of the work, no API, no client-state bugs, very fast to build. Rails’ conventions do a lot of the thinking for you.
• Less good: very rich client-side interactions get awkward. You’ll write some JavaScript anyway, and Stimulus controllers can sprawl if nobody keeps them tidy. Hiring “Hotwire developers” is harder than hiring React developers.

Inertia + React

• Good: the full React ecosystem, with Rails still doing what it’s best at. No API, no duplicated validation, no separate auth. The mental model is simple: controllers return props.
• Less good: you now have a JavaScript build, a Node toolchain and two sets of dependencies to keep updated. Server-side rendering needs a Node process alongside Rails. And it’s a smaller community than either Rails or Next.js, so you’ll occasionally be the first to hit a problem.

Separate frontend

• Good: independent teams and deploys, the best tooling for very rich UIs, an API you can reuse for mobile.
• Less good: this is the most expensive option by a long way. Two apps, two deploys, an API contract to version, auth across domains, validation in two places, and a whole class of “the frontend and backend disagree” bugs. It’s easy to underestimate.

What we usually recommend

• New B2B product, small team, mostly Rails developers: Hotwire. Add React islands only for the screens that really need them.
• Team with strong React skills building a Rails app: Inertia with React. You get most of React’s benefits without paying for an API.
• Product with a mobile app, a public API, or a separate frontend team: Rails API plus a separate React or Next.js frontend — and budget for the extra cost from day one.
• Not sure: start with Hotwire. Moving specific screens to React later is far easier than collapsing a separate frontend back into a monolith.

A note on mobile

If mobile apps are on the roadmap, add one more option: Hotwire Native, which wraps your server-rendered screens in native iOS and Android shells and lets you go fully native only where it matters. For apps that need a deeply native feel, React Native with a Rails API is the other path we use. Which one fits depends on the same questions above: how interactive the core is, and who is on the team.

The real answer

The frontend choice matters less than people think, as long as it matches your team and product. What really hurts projects is picking the most complex option “to be safe”, and then spending half the budget maintaining the plumbing between two apps.

Planning a big upgrade on either side first? We’ve written up Rails 7.2 → 8.0 and React 19 guides. If you’d like a second opinion on your stack before you commit to it, that’s what we do.

Sources

• Hotwire — hotwired.dev
• Turbo handbook — turbo.hotwired.dev
• Inertia.js — inertiajs.com
• inertia_rails gem — RubyGems
• Hotwire Native — native.hotwired.dev