# React on Rails: rendering React components inside Rails views, with SSR

> React on Rails wires React and Shakapacker into a Rails app so views can render components through a helper, with server-side rendering available. This review covers what it solves, how to install it, and where the OSS and Pro split changes the decision.

**shakacode/react_on_rails** — Integration of React + Webpack + Rails including server-side rendering of React, enabling a better developer experience and faster client performance.

- Repository: https://github.com/shakacode/react_on_rails
- Website: https://www.shakacode.com/react-on-rails/docs/
- Stars: 5,192 · Forks: 629
- Language: Ruby
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/shakacode-react-on-rails

## The problem React on Rails solves for Rails teams adding React

Rails teams that want React usually face a fork in the road. One path is to split the application into a Rails API and a separate JavaScript frontend, which means two deployments, a duplicated routing layer, and a session model that no longer comes from Rails. The other path is to keep Rails and drop React components into existing views, which is the problem this project addresses.

The README states the project integrates React into Ruby on Rails applications with Rails view helpers, server-side rendering, hot reloading, and automatic bundle generation. The audience is a team that already has Rails controllers, views and ActiveRecord models and does not want to rebuild that as a JSON API. The README frames the benefit directly: keep a single Rails app instead of splitting into a separate frontend and API.

That framing also tells you who it is not for. If your team has no Rails investment, or the product is React-first with Rails only as a persistence layer, the helper-based model adds indirection without solving anything. The project's value is proportional to how much Rails you already have.

## How react_component, Shakapacker and SSR fit together

The integration point is a Rails view helper. The README gives this example: `<%= react_component("HelloWorld", props: { name: "World" }) %>`. The helper resolves a registered component by name and emits the markup plus the props needed to hydrate it on the client. Bundling is handled by Shakapacker rather than by a bespoke webpack config, which is why the requirements list Shakapacker explicitly.

Server-side rendering exists in two forms. The README says you can use Rails-oriented SSR in the open-source gem, or upgrade to Pro for Node-rendered SSR, streaming SSR, and React Server Components. That is a real architectural distinction: the OSS path renders through a Rails-oriented mechanism, while Pro adds a separate Node renderer process. Streaming SSR and React Server Components are listed only under Pro.

The repository layout supports that split. The workspace in package.json lists `packages/react-on-rails`, `packages/react-on-rails-pro`, and `packages/react-on-rails-pro-node-renderer` as separate npm workspaces, and there is a top-level `react_on_rails_pro` directory alongside `react_on_rails`. The Pro licence also lives in the repo as `REACT-ON-RAILS-PRO-LICENSE.md`, so the commercial boundary is visible in the source tree rather than hidden behind a separate distribution.

## Installing React on Rails and rendering a first component

For a new application the README gives a four-command path. The first block creates the app, prepares the database and starts the dev process:

```bash
npx create-react-on-rails-app my-app
cd my-app
bin/rails db:prepare
bin/dev
```

One caveat sits right next to this in the README: new apps default to React on Rails Pro for React 19.2 support, and you pass `--standard` only when you intentionally want an open-source-only setup. If you are evaluating the OSS gem, that default matters before you run anything.

For an existing Rails app, the README documents two commands. The first adds the gem with the strict flag, the second runs the install generator:

```bash
bundle add react_on_rails --strict
bundle exec rails generate react_on_rails:install
bin/dev
```

The generator is where Shakapacker configuration and the component registration scaffolding get written. After that, a component can be rendered from any Rails view with the helper in an ERB template:

```erb
<%= react_component("HelloWorld", props: { name: "World" }) %>
```

If the setup does not come together, the README points at a diagnostic task rather than a troubleshooting checklist:

```bash
bundle exec rake react_on_rails:doctor
```

Before any of this, check the requirements the README lists: Ruby on Rails >= 5.2, Shakapacker >= 6.0 with autobundling requiring >= 7.0, Ruby >= 3.3, Node.js >= 18, and a JavaScript package manager such as pnpm, npm, yarn, or bun. The CI-tested ranges are narrower than the minimums: Shakapacker 8.2.0 to 10.3.1 and Ruby 3.3 to 4.0.

## Where React on Rails stops being the right tool

The sharpest limitation is the OSS and Pro boundary. The README lists Node renderer support, streaming SSR, React Server Components, fragment caching, and TanStack Router SSR as Pro features. If your application needs streaming SSR or React Server Components, the open-source gem alone does not provide them, and the README's own default for new apps reflects that.

The second constraint is the dependency surface. React on Rails does not bundle JavaScript by itself; it sits on Shakapacker, which sits on webpack or Rspack. That means a Shakapacker upgrade is effectively a React on Rails upgrade, and the README's tested range (8.2.0 to 10.3.1) is the window where the maintainers have verified the combination. Teams pinned to an older Shakapacker should treat this as a migration project, not a gem bump.

The third is the version history. The README warns that v15 material was retracted and points to an upgrade guide before using it, and it maintains separate documentation branches for v11 through v15. A project with that many historical branches is telling you that upgrades are a real cost. If you are on an old major version, budget for the upgrade guide rather than assuming a drop-in replacement.

Finally, if your team has already built a React SPA with its own router and API client, adopting this means unwinding that architecture. The helper model assumes Rails owns routing and the initial render.

## React on Rails compared with Inertia Rails and Vite Rails

The two alternatives that show up in the same search space are Inertia Rails and Vite Rails, and the difference is architectural rather than cosmetic.

Inertia Rails takes the position that the server returns page props and a single client-side adapter handles navigation. There is no per-component view helper; the client owns routing after the first load. React on Rails instead keeps Rails views as the composition layer, with `react_component` placing individual components into ERB. If your pages are assembled from several independent components inside a Rails layout, the helper model maps more directly. If your app behaves like a single-page application with server-provided props, Inertia's model is closer to the mental shape.

Vite Rails is a bundling answer, not a rendering answer. It swaps the asset pipeline integration for Vite. React on Rails does bundle through Shakapacker, and the README lists Rspack support as part of that bundling story, so the two projects overlap on the build step but not on SSR or the view helper. Choosing Vite Rails does not give you server-side rendering of components; choosing React on Rails gives you both the helper and the SSR path, with the bundler coming from Shakapacker.

That is the trade to weigh: React on Rails is a larger, more opinionated integration that covers rendering and bundling together, while the alternatives each solve one half.

## Maintenance, licensing and the Pro upgrade path

The repository is not archived and the last push was on 2026-09-22. The most recent release listed is v17.1.0 on 2026-09-19, preceded by release candidates v17.1.0.rc.5 and v17.1.0.rc.3 earlier that month. The README states the docs cover React on Rails 17, and the npm workspace package.json still carries version `17.0.0-rc.6`, which is a workspace manifest rather than the published gem version.

On licensing, the repository's licence field is NOASSERTION, and the README displays an MIT badge linking to `LICENSE.md`. There is also a separate `REACT-ON-RAILS-PRO-LICENSE.md` at the repository root and a `LICENSES/` directory. The README describes Pro as ShakaCode Trust-Based Commercial Licensing: free in development, test, CI, and staging for everyone; free in production for small organizations (under 10 people, under $1M revenue, under $1M raised) and for charities, schools, and hospitals at any size; larger organizations subscribe at $1,800 per year for the whole organization. The README notes no license key is needed to run it, and a key from a subscription only marks your pages `Licensed`.

That last detail is worth reading carefully. Because Pro runs without a key and the key only changes page marking, the enforcement model is trust-based rather than technical. Whether that fits your organization is a policy question, not an engineering one. Check the actual licence files rather than the badge before you rely on either tier.

## Conclusion

Adopt React on Rails if you are keeping a Rails app as the source of truth for routing, data and sessions, and you want React components rendered from ERB rather than a separate frontend. Do not adopt it if you have already committed to a standalone SPA with its own API layer, or if you need React 19.2 support in the open-source gem alone, since the README states new apps default to Pro for that. Verify three things before committing: that your Shakapacker version satisfies the requirement, that your production SSR throughput needs sit inside the OSS path, and that the Pro licence terms match your organization's size and revenue.

## FAQ

### What is React on Rails?

It is an integration that renders React components inside Ruby on Rails applications. The README describes Rails view helpers, server-side rendering, hot reloading, and automatic bundle generation, with Shakapacker handling the bundling.

### Does anybody still use Ruby on Rails?

The React on Rails repository is not archived and the last push was on 2026-09-22, with v17.1.0 released on 2026-09-19. The README states the current documentation covers React on Rails 17 and links to historical docs for v11 through v15.

### Is Ruby on Rails still relevant in 2026?

The repository is not archived and the last push was on 2026-09-22, with v17.1.0 released on 2026-09-19. The README states the current documentation covers React on Rails 17.

### What is Ruby on Rails vs React?

They are not competing layers. Rails is the server framework that owns routing, controllers and views, while React is the component library. React on Rails exists precisely to combine the two: the README describes rendering React components from Rails views with a helper.

## Sources

- [Issues](https://github.com/shakacode/react_on_rails/issues)
- [Project website](https://www.shakacode.com/react-on-rails/docs/)
- [README](https://github.com/shakacode/react_on_rails/blob/main/README.md)
- [Releases](https://github.com/shakacode/react_on_rails/releases)
- [shakacode/react_on_rails on GitHub](https://github.com/shakacode/react_on_rails)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shakacode-react-on-rails