Docs: add competitive comparison with alternatives#2641
Conversation
New doc comparing React on Rails (OSS + Pro) against alternatives with a feature matrix, per-option overviews, and a decision guide. Links added from introduction, docs README, and the legacy integration-options page. Closes #2637 Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdded a new comparative documentation page "Comparison with Alternatives" and inserted cross-reference links to it from existing docs; no code, API, or behavioral changes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4b896ce989
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| **Trade-offs:** | ||
|
|
||
| - No server-side rendering — all rendering happens in the browser |
There was a problem hiding this comment.
This bullet is factually incorrect: Inertia.js supports server-side rendering, so stating that it has "No server-side rendering" can mislead teams evaluating frameworks for SEO or first-render performance. Because this page is positioned as a decision guide, the incorrect capability claim materially affects architecture choices and should be corrected (and kept consistent with the feature matrix row).
Useful? React with 👍 / 👎.
Greptile SummaryAdds a new competitive comparison doc (
Confidence Score: 2/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["docs/oss/introduction.md"] -->|cross-link| D["docs/oss/getting-started/comparison-with-alternatives.md"]
B["docs/README.md"] -->|cross-link| D
C["docs/oss/building-features/rails-webpacker-react-integration-options.md"] -->|cross-link| D
D -->|links to| E["docs/oss/getting-started/oss-vs-pro.md"]
D -->|links to| F["docs/oss/getting-started/quick-start.md"]
D -->|links to| G["docs/oss/migrating/migrating-from-react-rails.md"]
Last reviewed commit: 4b896ce |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
Inertia.js SSR support is misrepresented
The feature matrix shows — for Inertia.js server-side rendering, and the Inertia overview section (line 41) states "No server-side rendering — all rendering happens in the browser." This is factually incorrect.
Inertia.js has supported SSR since v1, including with the Rails adapter (inertia-rails). It uses a Node.js process to pre-render pages on the server, similar in concept to React on Rails Pro's Node renderer. The Rails adapter documentation provides full setup instructions for SSR with Vite.
This is a significant factual error in a comparison document that could undermine the credibility of the entire page. The SSR row should show ✓ for Inertia.js, and the trade-offs section should be updated accordingly (e.g., SSR requires a separate Node.js process rather than being unavailable).
| | Auto-bundling | — | — | Import maps | ✓ | ✓ | | ||
| | Rspack / Webpack support | — | ✓ (Vite default) | — | ✓ | ✓ | | ||
| | Hot module replacement | — | ✓ | Turbo morphing | ✓ | ✓ | | ||
| | Type-safe routing | — | ✓ (Ziggy) | — | — | ✓ (TanStack Router) | |
There was a problem hiding this comment.
Ziggy is not a type-safe router
Labeling Ziggy as providing "type-safe routing" (✓ (Ziggy)) is misleading. Ziggy is a named route helper library that generates URLs from Laravel/Rails server-side route definitions — it provides a route() function, not a client-side router. While it does offer TypeScript type definitions for route name autocompletion, this is fundamentally different from what TanStack Router provides (a full client-side router with type-safe route params, search params, loaders, etc.).
Consider changing this to ✓ (Ziggy) under a "Named route helpers" row instead, or rewording to clarify the distinction (e.g., ✓ (Ziggy¹) with a footnote: "Ziggy provides typed named routes, not client-side routing").
Review: Comparison with Alternatives docGood addition overall — the structure (feature matrix, per-option sections, decision table) serves different reader types well, and all internal links resolve correctly. A few factual accuracy issues need fixing before merge. High priorityInertia.js SSR support is incorrect. The document states Inertia has no SSR (both in the feature matrix and the Trade-offs section), but Inertia.js v2 added SSR support via Medium priorityreact-rails GitHub URL may point to the wrong org. The doc links to "Rspack / Webpack support" column with "Vite default" cell is confusing. The column header implies the row is about Rspack/Webpack specifically, but the Inertia cell says "Vite default" while the Hotwire cell says "Import maps". These are not answers to the same question as the column header. Consider renaming the column to something like "Bundler support" and noting that HMR/Rspack availability comes from the bundler layer, not the integration itself. Low priority
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
Inertia.js v2 added SSR support via @inertiajs/server — this cell should not be —. Consider updating to something like ✓ (v2+) or Limited with a footnote. See Inertia SSR docs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| | Streaming SSR | — | — | Turbo Streams | — | ✓ | | ||
| | Code splitting with SSR | — | — | N/A | — | ✓ | | ||
| | Auto-bundling | — | — | Import maps | ✓ | ✓ | | ||
| | Rspack / Webpack support | — | ✓ (Vite default) | — | ✓ | ✓ | |
There was a problem hiding this comment.
The column header "Rspack / Webpack support" and the cell value "Vite default" answer different questions. Inertia is actually bundler-agnostic (works with Webpack, Rspack, and Vite); the "Vite default" describes its starter kits, not its capability. Similarly, "Import maps" in the Hotwire cell isn't really about Rspack/Webpack. Consider renaming this column to "Bundler" or "Build tooling" to better cover the range of values shown.
|
|
||
| ### react-rails | ||
|
|
||
| [react-rails](https://github.com/reactjs/react-rails) was one of the first gems to integrate React with Rails. It provides a `react_component` view helper and basic ExecJS-based server rendering. However, the project has seen minimal maintenance in recent years and lacks support for modern React features like streaming SSR, code splitting, or React Server Components. |
There was a problem hiding this comment.
The react-rails gem was transferred to ShakaCode — the canonical repo URL may now be https://github.com/shakacode/react-rails rather than https://github.com/reactjs/react-rails. Please verify before merging to avoid linking readers to a stale/archived location.
|
|
||
| **Trade-offs:** | ||
|
|
||
| - No server-side rendering — all rendering happens in the browser |
There was a problem hiding this comment.
This is factually incorrect as of Inertia.js v2. Inertia does support SSR via @inertiajs/server. This line should be updated — for example: "SSR requires additional setup via @inertiajs/server" or similar, rather than "No server-side rendering".
…section - Add note that both react-rails and React on Rails are maintained by ShakaCode with a straightforward migration path - Remove redundant bullet about incremental migration (the API compatibility is already covered in the react-rails section) Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
Factual inaccuracy: Inertia.js has supported server-side rendering since v1.0 via a dedicated Node.js SSR server (@inertiajs/react + createServer). Marking it as — (unsupported) is incorrect and could mislead readers comparing options.
Suggested correction: Limited (Node.js) or ✓ (Node.js) with a note that it requires a separate Node SSR server setup.
This also affects the trade-off on line 43 that states "No server-side rendering — all rendering happens in the browser" — that statement is outdated/incorrect.
|
|
||
| **Trade-offs:** | ||
|
|
||
| - No server-side rendering — all rendering happens in the browser |
There was a problem hiding this comment.
Factual inaccuracy: Inertia.js has supported SSR since v1.0. This trade-off bullet should either be removed or updated to reflect that SSR is available but requires an additional Node.js server process.
| - No server-side rendering — all rendering happens in the browser | |
| - SSR requires a separate Node.js server process — adds infrastructure complexity compared to Rails-native SSR solutions |
| | ------------------------ | :--------------: | :--------------: | :--------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | ✓ (ExecJS) | ✓ (Node renderer) | | ||
| | React Server Components | — | — | N/A | — | ✓ | | ||
| | Streaming SSR | — | — | Turbo Streams | — | ✓ | |
There was a problem hiding this comment.
Misleading cell: "Turbo Streams" is listed under "Streaming SSR" for Hotwire, but these are fundamentally different concepts. Turbo Streams are for real-time partial page updates over WebSocket/SSE (e.g., broadcasting HTML fragments), not streaming SSR in the React sense (progressively flushing an HTML shell while data loads). Using this cell suggests Hotwire has a comparable streaming rendering feature, which is not accurate.
Suggest changing the cell to — or N/A for Hotwire, since streaming SSR is a React-specific concept that doesn't apply here.
| [react-rails](https://github.com/reactjs/react-rails) was one of the first gems to integrate React with Rails. It provides a `react_component` view helper and basic ExecJS-based server rendering. However, the project has seen minimal maintenance in recent years and lacks support for modern React features like streaming SSR, code splitting, or React Server Components. | ||
|
|
||
| Both react-rails and React on Rails are maintained by [ShakaCode](https://www.shakacode.com/), and switching from react-rails to React on Rails is straightforward since both use a `react_component` view helper with the same API. See the [migration guide](../migrating/migrating-from-react-rails.md) for details. |
There was a problem hiding this comment.
Contradictory messaging: The paragraph opens by saying react-rails "has seen minimal maintenance in recent years", then immediately says it is "maintained by ShakaCode". This reads as self-contradictory and could confuse readers.
If ShakaCode actively maintains react-rails, the "minimal maintenance" characterization (also in the feature matrix) should be updated. If maintenance truly is minimal, the sentence claiming ShakaCode maintains both gems needs clarification (e.g., "ShakaCode maintains both gems, though active feature development for react-rails is limited — new features are focused on React on Rails").
| - Replaces Rails views entirely — you cannot mix ERB and React on the same page | ||
| - Requires adopting Inertia's conventions for data passing and page transitions | ||
|
|
||
| **Best for:** New apps where you want a SPA-like experience with server-side routing and don't need SSR. |
There was a problem hiding this comment.
This "Best for" guidance should be updated once the SSR inaccuracy above is resolved. If Inertia supports SSR, recommending it only for "no SSR needed" cases undersells it and could misdirect users who need SSR but prefer Inertia's SPA conventions.
Review: Documentation — Comparison with AlternativesOverall this is a well-structured and genuinely useful doc. The layout, cross-linking, and decision table are all solid. A few factual issues need addressing before merge. Critical: Inertia.js SSR support is incorrectThe feature matrix marks Inertia.js "Server-side rendering" as Inertia.js has supported SSR since v1.0 via See inline comments on lines 9, 43, and 47 for specifics. Misleading: "Turbo Streams" under "Streaming SSR"The feature matrix lists "Turbo Streams" as Hotwire's answer to the "Streaming SSR" row. These are unrelated concepts — Turbo Streams are real-time HTML fragment broadcasts over WebSocket/SSE, while streaming SSR means progressively flushing the initial HTML response. Using this cell implies Hotwire has comparable streaming rendering, which is not accurate. See inline comment on line 11. Contradictory: react-rails maintenance descriptionThe react-rails section says the project "has seen minimal maintenance in recent years" in one sentence and then "Both react-rails and React on Rails are maintained by ShakaCode" in the next. The feature matrix also marks its active maintenance as "Minimal." The messaging should be reconciled — either clarify that ShakaCode provides security/compatibility fixes but no new features, or update the matrix. See inline comment on lines 25–27. Minor notes
Once the Inertia SSR issue is resolved the rest of the doc looks good to go. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Line 14: Update the table row header text that currently reads "Rspack /
Webpack support" to a neutral label like "Bundler support" or "Bundler
ecosystem" so the comparison cells (e.g., the cell containing "✓ (Vite default)"
for Inertia.js) no longer mix bundler ecosystems with specific tools; modify the
header string in the file so the row now reads "Bundler support" (or your chosen
neutral label) while leaving the existing cell values unchanged.
- Around line 43-45: Update the three bullet points to correct overstatements:
change "No server-side rendering — all rendering happens in the browser" to
indicate Inertia supports SSR (e.g., "Server-side rendering is supported via a
Node.js SSR process; client-side rendering remains the default"), replace
"Replaces Rails views entirely — you cannot mix ERB and React on the same page"
with a qualified statement about incremental adoption and per-request behavior
(e.g., "Supports incremental adoption with ERB and React coexisting; each
request/action is either an Inertia response or a traditional response and
layout-level mixing is possible using helpers like inertia_rendering?"), and
soften "Requires adopting Inertia's conventions for data passing and page
transitions" to note conventions are recommended but can be adapted; ensure the
revised bullets mention the Node.js SSR capability and the inertia_rendering?
helper by name so readers can locate relevant docs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9dd10166-a942-4706-a7cd-7286b1d689f7
📒 Files selected for processing (1)
docs/oss/getting-started/comparison-with-alternatives.md
Add Vite Ruby as a column in the feature comparison matrix, a dedicated overview section covering strengths and trade-offs, a side-by-side Vite vs Rspack build tooling table, and updated decision framework entries. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
Factual inaccuracy: Inertia.js v2 (released January 2024) added server-side rendering support. The — here is incorrect. It should be something like ✓ (opt-in) or Limited with a note that SSR is opt-in and requires a Node.js server.
| | Streaming SSR | — | — | Turbo Streams | — | — | ✓ | | ||
| | Code splitting with SSR | — | — | N/A | — | — | ✓ | | ||
| | Auto-bundling | — | — | Import maps | — | ✓ | ✓ | | ||
| | Rspack / Webpack support | — | ✓ (Vite default) | — | ✓ (Vite/Rollup) | ✓ | ✓ | |
There was a problem hiding this comment.
Misleading cell value: The column is "Rspack / Webpack support" but the Inertia.js cell reads ✓ (Vite default). Vite is neither Rspack nor Webpack — it's a completely different bundler. Inertia.js is bundler-agnostic and works with Vite, Webpack, Rspack, etc., but the value in this cell misrepresents what the column is asking. Consider renaming the column to "Modern build tool support" or splitting it, and updating the cell to reflect that Inertia.js is bundler-agnostic.
| | Auto-bundling | — | — | Import maps | — | ✓ | ✓ | | ||
| | Rspack / Webpack support | — | ✓ (Vite default) | — | ✓ (Vite/Rollup) | ✓ | ✓ | | ||
| | Hot module replacement | — | ✓ | Turbo morphing | ✓ | ✓ | ✓ | | ||
| | Type-safe routing | — | ✓ (Ziggy) | — | — | — | ✓ (TanStack Router) | |
There was a problem hiding this comment.
Inaccuracy: Ziggy provides named Rails routes in JavaScript — it is not a type-safe routing solution, and it's not Inertia-specific (it works with any JS frontend). Inertia.js itself uses the server-side Rails router for page navigation, so there's no client-side router to be "type-safe". This cell should be — or a note like ✓ (via Ziggy, not type-safe) to avoid misleading comparisons with TanStack Router's actual type safety.
|
|
||
| [react-rails](https://github.com/reactjs/react-rails) was one of the first gems to integrate React with Rails. It provides a `react_component` view helper and basic ExecJS-based server rendering. However, the project has seen minimal maintenance in recent years and lacks support for modern React features like streaming SSR, code splitting, or React Server Components. | ||
|
|
||
| Both react-rails and React on Rails are maintained by [ShakaCode](https://www.shakacode.com/), and switching from react-rails to React on Rails is straightforward since both use a `react_component` view helper with the same API. See the [migration guide](../migrating/migrating-from-react-rails.md) for details. |
There was a problem hiding this comment.
Needs verification: The claim that react-rails is "maintained by ShakaCode" may be misleading. The repository lives at github.com/reactjs/react-rails under the reactjs GitHub org, not under shakacode. While justin808 is a contributor/maintainer, the phrasing could give a false impression of organizational ownership. Consider: "React on Rails is the actively maintained successor to react-rails, with shared authorship."
|
|
||
| **Trade-offs:** | ||
|
|
||
| - No server-side rendering — all rendering happens in the browser |
There was a problem hiding this comment.
Factual inaccuracy: Inertia.js v2 supports SSR (Node.js-based, opt-in). This bullet is incorrect for current versions. It should be updated, e.g.: "SSR is opt-in and requires a separate Node.js rendering server — not as integrated as React on Rails' built-in SSR."
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | | ||
| | React Server Components | — | — | N/A | — | — | ✓ | | ||
| | Streaming SSR | — | — | Turbo Streams | — | — | ✓ | |
There was a problem hiding this comment.
Apples-to-oranges comparison: "Turbo Streams" is not "Streaming SSR" in the React sense. Turbo Streams are a mechanism for sending HTML fragments over WebSockets/SSE to update parts of a page — fundamentally different from React's renderToPipeableStream / HTTP streaming SSR. Using this cell to imply Hotwire has "Streaming SSR" will confuse readers. Consider N/A or — here, since SSR is not a concept that applies to Hotwire the same way.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Around line 93-94: The table and surrounding comparison text include hard
numeric claims ("~53–270ms incremental builds", "~20x vs Webpack", "10–100x
faster SSR"); either add a citation and brief description of the benchmark
methodology/source for each assertion or replace the numbers with softened
wording (e.g., "significantly faster incremental builds", "substantially faster
than Webpack", "much faster SSR") to avoid presenting uncited hard facts; update
the specific strings in the comparison rows and any matching sentences that
reference them so the wording is consistent and, if adding citations, include a
short parenthetical reference or footnote pointing to the benchmark/source.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 60b1c014-414b-4652-9d07-c9344d7e2220
📒 Files selected for processing (1)
docs/oss/getting-started/comparison-with-alternatives.md
Review: Comparison with Alternatives docGood addition overall — a comparison doc is genuinely useful for developers evaluating Rails frontend options. The structure (feature matrix, per-option overview, decision table) is clear and the Vite vs Rspack deep-dive adds real value. However, there are several factual inaccuracies that should be fixed before merging. See inline comments for specifics; summary below: Factual issues (must fix)
Minor issues (nice to fix)
The Vite Ruby section and the decision table are well-balanced and accurate. The main risk is credibility: a comparison doc that misrepresents a competitor's features will erode trust from readers who know those tools. |
Add concrete performance numbers from rspack-contrib/performance-compare benchmark suite: dev cold startup (Rspack 3-5x faster), HMR (tied at sub-150ms), production builds (Vite 8 1.4-1.7x faster), and memory usage (Rspack 2-3x less). Includes Webpack numbers for context. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Vite Ruby doesn't restrict routing choices — you can use React Router, TanStack Router, or any other client-side router. Split the old "Rails integration" / "React component helpers" rows into "Rails view integration" and "Client-side routing" to be accurate. Update feature matrix to show Vite supports BYO type-safe routing. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
|
||
| [react-rails](https://github.com/reactjs/react-rails) was one of the first gems to integrate React with Rails. It provides a `react_component` view helper and basic ExecJS-based server rendering. However, the project has seen minimal maintenance in recent years and lacks support for modern React features like streaming SSR, code splitting, or React Server Components. | ||
|
|
||
| Both react-rails and React on Rails are maintained by [ShakaCode](https://www.shakacode.com/), and switching from react-rails to React on Rails is straightforward since both use a `react_component` view helper with the same API. See the [migration guide](../migrating/migrating-from-react-rails.md) for details. |
There was a problem hiding this comment.
Factual inaccuracy: react-rails is not maintained by ShakaCode.
The react-rails gem lives under the reactjs GitHub organization, not ShakaCode. ShakaCode only maintains React on Rails.
Suggested fix:
| Both react-rails and React on Rails are maintained by [ShakaCode](https://www.shakacode.com/), and switching from react-rails to React on Rails is straightforward since both use a `react_component` view helper with the same API. See the [migration guide](../migrating/migrating-from-react-rails.md) for details. | |
| [react-rails](https://github.com/reactjs/react-rails) is a separate project under the `reactjs` GitHub organization. Switching from react-rails to React on Rails is straightforward since both use a `react_component` view helper with a compatible API. See the [migration guide](../migrating/migrating-from-react-rails.md) for details. |
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
Factual inaccuracy: Inertia.js does support SSR.
Inertia.js v1.0 (released 2023) added official server-side rendering support for all adapter frameworks (React, Vue, Svelte). The — here is incorrect — it should be something like ✓ (opt-in) or ✓ (v1.0+).
This error also propagates to the "Trade-offs" section below (line 44) and the "Best for" guidance (line 48), both of which claim Inertia has no SSR.
|
|
||
| **Trade-offs:** | ||
|
|
||
| - No server-side rendering — all rendering happens in the browser |
There was a problem hiding this comment.
Inertia.js SSR claim is incorrect.
Inertia.js v1.0 added official SSR support — this trade-off should be removed or corrected. The SSR row in the feature matrix above also needs updating.
| - No server-side rendering — all rendering happens in the browser | |
| - SSR is opt-in and requires a separate Node.js server (added in v1.0) — not as integrated as React on Rails |
| - Replaces Rails views entirely — you cannot mix ERB and React on the same page | ||
| - Requires adopting Inertia's conventions for data passing and page transitions | ||
|
|
||
| **Best for:** New apps where you want a SPA-like experience with server-side routing and don't need SSR. |
There was a problem hiding this comment.
Since Inertia.js does support SSR (v1.0+), the "don't need SSR" qualifier here is incorrect.
| **Best for:** New apps where you want a SPA-like experience with server-side routing and don't need SSR. | |
| **Best for:** New apps where you want a SPA-like experience with server-side routing, using a controller-driven architecture across React, Vue, or Svelte. |
| | **Client-side routing** | Any React router (React Router, TanStack, etc.) | Any React router; TanStack Router SSR in Pro | | ||
| | **Plugin ecosystem** | Vite/Rollup plugins | Webpack/Rspack plugins | | ||
|
|
||
| **Key takeaway:** As pure bundlers, Vite and Rspack are both excellent — Rspack starts dev faster and uses less memory, while Vite 8 produces production builds faster. HMR is a tie. But Vite is _only_ a bundler. Choosing Vite means giving up React on Rails' `react_component` helper, automatic props passing from controllers, built-in SSR, and auto-bundling. With Rspack, you get competitive build speeds while retaining the full React on Rails integration layer. If you need SSR, the gap widens further: React on Rails provides SSR out of the box, while Vite requires building a custom Node.js rendering pipeline and wiring it into Rails yourself. |
There was a problem hiding this comment.
"Vite 8" may not be accurate.
As of mid-2025, Vite 6 was the latest stable release. "Vite 8 (powered by Rolldown)" appears to be a forward-looking or hallucinated reference. The benchmark tables above also don't specify which Vite version was used. Please verify the actual version from the referenced rspack-contrib/performance-compare benchmark and update accordingly — both in this sentence and in the benchmark tables themselves (which should label the exact version tested).
Review: Comparison with AlternativesGood addition overall — a comparison guide is genuinely useful for people evaluating React on Rails. The structure is clear and the decision table is helpful. However, there are a few factual inaccuracies that need fixing before merge, since incorrect claims about competitors will undermine trust in the document. Must Fix: Inertia.js SSR is incorrect throughout — Inertia.js v1.0 (released 2023) added official SSR support for React, Vue, and Svelte adapters. The feature matrix marks it as unsupported, the trade-offs section says 'No server-side rendering', and the Best for guidance says 'don't need SSR'. All three need updating (see inline comments). Must Fix: react-rails ownership is wrong — Line 28 states 'Both react-rails and React on Rails are maintained by ShakaCode'. The react-rails gem lives under the reactjs GitHub organization, not ShakaCode. This will be noticed by react-rails users and hurts the doc's credibility (see inline comment). Must Fix: 'Vite 8' may not exist — The key takeaway paragraph references 'Vite 8 (powered by Rolldown)'. As of mid-2025 the latest stable Vite was v6. This appears to be an AI-generated forward reference. The benchmark tables also omit exact tool versions — please verify against the rspack-contrib/performance-compare source and cite the versions actually tested (see inline comment). Minor points: The 'Rspack / Webpack support' row for Inertia.js shows 'Vite default' which is misleading — Inertia works with any bundler. The 'Auto-bundling' row for Hotwire shows 'Import maps', but import maps are a Rails/browser feature, not a Hotwire feature. The benchmarks section would benefit from version stamps and a collection date. |
Review: Comparison with Alternatives docGood addition overall. The feature matrix format and decision table are clear and useful. A few factual accuracy issues need attention before merging. Factual ErrorsInertia.js SSR: The document states Inertia.js has no SSR (shows dash in the matrix and says "No server-side rendering — all rendering happens in the browser"). This is incorrect. Inertia.js has had first-party SSR support since v1.0 via a Node.js server for both React and Vue adapters. This steers readers away from Inertia.js based on a false premise. Rspack/Webpack support column for Inertia.js: The cell reads "Vite default" but Vite uses esbuild and Rollup, not Rspack/Webpack. Inertia.js is bundler-agnostic and works with Vite, Webpack, Rspack, or any other bundler. The value is misleading about both what Vite is and what Inertia.js supports. Benchmark neutrality: The performance numbers come from rspack-contrib/performance-compare, maintained by the Rspack team. Presenting these without noting the provenance could mislead readers into treating them as neutral third-party data. A brief caveat would help readers evaluate the numbers appropriately. Minor IssuesVite 8 (powered by Rolldown): Verify this version number is accurate at time of merge. Cross-link in introduction.md: The new sentence mentions Inertia.js, Hotwire, and react-rails but the new doc also prominently covers Vite Ruby. Update the teaser line to reflect all covered options. react-rails maintenance label: The table shows "Minimal" but the prose notes ShakaCode maintains both gems. Consider clarifying what "Minimal" means in practice (security patches only, no new features, etc.). |
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
The — here is factually incorrect. Inertia.js has supported SSR since v1.0 via a dedicated Node.js server. See https://inertiajs.com/server-side-rendering. This should be updated to ✓ (Node.js) or similar.
| | React Server Components | — | — | N/A | — | — | ✓ | | ||
| | Streaming SSR | — | — | Turbo Streams | — | — | ✓ | | ||
| | Code splitting with SSR | — | — | N/A | — | — | ✓ | | ||
| | Auto-bundling | — | — | Import maps | — | ✓ | ✓ | |
There was a problem hiding this comment.
The value ✓ (Vite default) is misleading in a column titled "Rspack / Webpack support". Vite uses esbuild + Rollup — it is not Rspack or Webpack. Inertia.js is bundler-agnostic and can work with Vite, Webpack, Rspack, or any other bundler. Consider splitting this into two rows ("Vite / Rollup support" and "Rspack / Webpack support") or reframing the column as "Modern bundler support".
| - Built-in form helpers and shared data conventions | ||
|
|
||
| **Trade-offs:** | ||
|
|
There was a problem hiding this comment.
This trade-off is factually wrong. Inertia.js does support server-side rendering — it ships a first-party SSR adapter that renders components to HTML on the server via Node.js. See https://inertiajs.com/server-side-rendering. This should be corrected or removed.
| | Project size | Rspack | Vite | Webpack | | ||
| | -------------- | :----: | :----: | :------: | | ||
| | 1k components | 129 ms | 133 ms | 444 ms | | ||
| | 5k components | 105 ms | 147 ms | 1,831 ms | |
There was a problem hiding this comment.
Worth noting that rspack-contrib/performance-compare is maintained by the Rspack team, so these benchmarks come from the vendor. Consider adding a short disclosure, e.g. "Note: benchmarks are from the Rspack project's own test suite — treat as directional rather than independently verified."
|
|
||
| **Memory usage in development** (lower is better): | ||
|
|
||
| | Project size | Rspack | Vite | Webpack | |
There was a problem hiding this comment.
"Vite 8 (powered by Rolldown)" — please verify this version number is accurate. If Vite 8 has not yet shipped, this will look incorrect to readers and undermine trust in the benchmarks.
|
|
||
| - ❌ You're building a standalone SPA with a separate API backend | ||
|
|
||
| For a detailed comparison with Inertia.js, Hotwire, and react-rails, see [Comparison with Alternatives](./getting-started/comparison-with-alternatives.md). |
There was a problem hiding this comment.
The linked doc also covers Vite Ruby prominently, but it's not mentioned here. Suggest updating to: "For a detailed comparison with Inertia.js, Hotwire, Vite Ruby, and react-rails, see Comparison with Alternatives."
| For a detailed comparison with Inertia.js, Hotwire, and react-rails, see [Comparison with Alternatives](./getting-started/comparison-with-alternatives.md). | |
| For a detailed comparison with Inertia.js, Hotwire, Vite Ruby, and react-rails, see [Comparison with Alternatives](./getting-started/comparison-with-alternatives.md). |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0efc43b479
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
The matrix currently marks Inertia.js as having no server-side rendering, but Inertia provides SSR support, so this entry can mislead teams using this table for framework selection when SEO or first-render performance matters. Please update this cell to reflect SSR availability (even if it is optional/manual) so the comparison is factually accurate.
Useful? React with 👍 / 👎.
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | | ||
| | ------------------------ | :--------------: | :--------------: | :--------------: | :-------------: | :------------------: | :-----------------: | | ||
| | Server-side rendering | Limited (ExecJS) | — | N/A | — | ✓ (ExecJS) | ✓ (Node renderer) | |
There was a problem hiding this comment.
This row says Vite Ruby has no SSR, but later in the same document the integration table states Vite SSR mode (manual Rails integration), so readers get contradictory guidance depending on which section they read first. The matrix should be aligned to indicate manual/DIY SSR instead of implying the capability is absent.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
♻️ Duplicate comments (3)
docs/oss/getting-started/comparison-with-alternatives.md (3)
44-46:⚠️ Potential issue | 🟠 MajorCorrect Inertia trade-offs to avoid factual overstatements.
Line 44 and Line 45 currently overstate limitations. Inertia supports SSR (via Node SSR setup), and ERB/Inertia can coexist incrementally; the per-action response mode is the actual constraint.
In current official docs, does Inertia.js support SSR for React, and can Inertia Rails coexist with traditional ERB views via incremental adoption?Suggested edit
-- No server-side rendering — all rendering happens in the browser -- Replaces Rails views entirely — you cannot mix ERB and React on the same page -- Requires adopting Inertia's conventions for data passing and page transitions +- Server-side rendering is supported via a Node.js SSR process (not the default Rails rendering path) +- Supports incremental adoption with ERB + Inertia pages coexisting; each action responds as either Inertia or traditional +- Uses Inertia conventions for data passing and navigation, which may require adapting existing patterns🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/getting-started/comparison-with-alternatives.md` around lines 44 - 46, Update the two bullet points that overstate Inertia's limitations: replace "No server-side rendering — all rendering happens in the browser" with a statement acknowledging Inertia supports SSR for React via Node-based SSR setups, and replace "Replaces Rails views entirely — you cannot mix ERB and React on the same page" with a line explaining Inertia Rails can be adopted incrementally and can coexist with ERB views (the real constraint is the per-action response mode), and keep a note referencing that adopting Inertia requires using its conventions for data passing and page transitions.
14-14:⚠️ Potential issue | 🟡 MinorRename this row to a neutral bundler dimension.
Line 14 mixes specific tools in the header while cells describe broader/default bundlers (e.g., Inertia + Vite). A neutral label keeps the matrix consistent.
Suggested edit
-| Rspack / Webpack support | — | ✓ (Vite default) | — | ✓ (Vite/Rollup) | ✓ | ✓ | +| Bundler ecosystem | — | ✓ (Vite default) | — | ✓ (Vite/Rollup) | ✓ | ✓ |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/getting-started/comparison-with-alternatives.md` at line 14, The table row header "Rspack / Webpack support" should be renamed to a neutral bundler dimension to avoid mixing specific tools with broader/default bundlers; update the header text (the string "Rspack / Webpack support" in the table row) to a neutral label such as "Bundler support (defaults)" or "Default bundler", leaving the existing cell values (e.g., "—", "✓ (Vite default)", "✓ (Vite/Rollup)") unchanged so the matrix remains consistent.
157-170:⚠️ Potential issue | 🟠 MajorUnsupported hard performance multipliers need substantiation or softening.
Lines 157 and 170 contain specific numeric performance claims ("~20x vs Webpack" for Rspack and "10–100x faster SSR" for Node renderer) that lack published benchmark methodology or sourcing within the documentation. Neither claim has a publicly available, methodology-documented benchmark in the React on Rails repository or official channels.
Either add inline citation to published benchmarks with methodology/environment details, or soften the language to claims like "substantially faster" and "significantly faster" until comprehensive benchmarks are published.
Suggested wording if sources are not added
-- Rspack support for faster builds (~20x vs Webpack) +- Rspack support for substantially faster builds than Webpack in large projects -- **Node renderer** — dedicated Node.js server for 10–100x faster SSR (replaces ExecJS) +- **Node renderer** — dedicated Node.js server for significantly faster SSR than ExecJS (replaces ExecJS)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/getting-started/comparison-with-alternatives.md` around lines 157 - 170, The numeric performance claims in the copy (e.g., "Rspack support for faster builds (~20x vs Webpack)" and "Node renderer — dedicated Node.js server for 10–100x faster SSR") must be either sourced or softened: either add inline citations to published benchmarks that include methodology/environment details and link them next to the phrases, or change the wording to non-quantitative language such as "substantially faster" for the Rspack line and "significantly faster SSR" for the "Node renderer" line (keep references to "renderToPipeableStream" and "Node renderer" intact to preserve context). Ensure the updated text replaces the exact phrases in the diff so the doc no longer claims unsupported numeric multipliers without citation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Around line 44-46: Update the two bullet points that overstate Inertia's
limitations: replace "No server-side rendering — all rendering happens in the
browser" with a statement acknowledging Inertia supports SSR for React via
Node-based SSR setups, and replace "Replaces Rails views entirely — you cannot
mix ERB and React on the same page" with a line explaining Inertia Rails can be
adopted incrementally and can coexist with ERB views (the real constraint is the
per-action response mode), and keep a note referencing that adopting Inertia
requires using its conventions for data passing and page transitions.
- Line 14: The table row header "Rspack / Webpack support" should be renamed to
a neutral bundler dimension to avoid mixing specific tools with broader/default
bundlers; update the header text (the string "Rspack / Webpack support" in the
table row) to a neutral label such as "Bundler support (defaults)" or "Default
bundler", leaving the existing cell values (e.g., "—", "✓ (Vite default)", "✓
(Vite/Rollup)") unchanged so the matrix remains consistent.
- Around line 157-170: The numeric performance claims in the copy (e.g., "Rspack
support for faster builds (~20x vs Webpack)" and "Node renderer — dedicated
Node.js server for 10–100x faster SSR") must be either sourced or softened:
either add inline citations to published benchmarks that include
methodology/environment details and link them next to the phrases, or change the
wording to non-quantitative language such as "substantially faster" for the
Rspack line and "significantly faster SSR" for the "Node renderer" line (keep
references to "renderToPipeableStream" and "Node renderer" intact to preserve
context). Ensure the updated text replaces the exact phrases in the diff so the
doc no longer claims unsupported numeric multipliers without citation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3bd42830-c336-466c-a199-3aef500b4a89
📒 Files selected for processing (1)
docs/oss/getting-started/comparison-with-alternatives.md
- Fix Inertia.js SSR: mark as supported (opt-in, Node.js) in feature matrix, trade-offs, and "Best for" guidance - Rename "Rspack / Webpack support" to "Bundler support" with accurate cell values for each framework - Remove Ziggy from type-safe routing row (it provides named routes, not type-safe client-side routing) - Clarify react-rails is in maintenance mode, maintained by ShakaCode - Remove "Turbo Streams" from Streaming SSR row (different concept) - Fix "Vite 8" references to "Vite" (unverified version number) - Add vendor disclosure for Rspack benchmarks Co-Authored-By: Claude Opus 4.6 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
docs/oss/getting-started/comparison-with-alternatives.md (1)
170-170:⚠️ Potential issue | 🟡 MinorSubstantiate or soften the SSR performance claim.
The "10–100x faster SSR" claim is not supported by any benchmark data in this document. The Vite vs Rspack benchmark section (Lines 87-145) covers dev startup, HMR, production builds, and memory usage—but not SSR rendering performance.
Either add benchmark data/citation for SSR performance or soften the wording to avoid presenting an unverified numeric claim.
💡 Suggested alternatives
Option 1 (soften):
- - **Node renderer** — dedicated Node.js server for 10–100x faster SSR (replaces ExecJS) + - **Node renderer** — dedicated Node.js server for dramatically faster SSR compared to ExecJSOption 2 (add citation):
- - **Node renderer** — dedicated Node.js server for 10–100x faster SSR (replaces ExecJS) + - **Node renderer** — dedicated Node.js server for significantly faster SSR (replaces ExecJS; see [internal benchmarks](link))🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/getting-started/comparison-with-alternatives.md` at line 170, The "10–100x faster SSR" claim in the "Node renderer — dedicated Node.js server for 10–100x faster SSR (replaces ExecJS)" line is unsupported; either provide a citation/benchmark to substantiate it or soften the language. Update the sentence in the "Node renderer" bullet: if adding data, reference a specific benchmark or external source (include brief methodology and numbers) and cite it inline; otherwise change the phrase to a non-numeric claim such as "significantly faster SSR" or "substantially improved SSR performance" to remove the unverified "10–100x" figure. Ensure the modified text and any added citation are consistent with the surrounding Vite vs Rspack benchmark section.
🧹 Nitpick comments (1)
docs/oss/getting-started/comparison-with-alternatives.md (1)
70-70: Optional: Vary sentence structure to improve readability.Three consecutive sentences begin with "Vite" which creates slight repetition. Consider varying the structure.
🎨 Suggested rewording
-[Vite Ruby](https://vite-ruby.netlify.app/) integrates the [Vite](https://vite.dev/) build tool with Rails. Vite uses esbuild for fast development builds and Rollup for optimized production bundles. The `vite_rails` gem provides asset tag helpers and a dev server proxy, but it is a **build tool only** — it does not provide React-specific helpers, server-side rendering, or a component rendering layer. +[Vite Ruby](https://vite-ruby.netlify.app/) integrates the [Vite](https://vite.dev/) build tool with Rails. The underlying build tool uses esbuild for fast development builds and Rollup for optimized production bundles. The `vite_rails` gem provides asset tag helpers and a dev server proxy, but it is a **build tool only** — it does not provide React-specific helpers, server-side rendering, or a component rendering layer.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/getting-started/comparison-with-alternatives.md` at line 70, The paragraph repeats "Vite" at the start of three sentences; reword to vary sentence openings and improve flow by referencing "Vite Ruby" and "vite_rails" differently—for example start the second sentence with "It" or "This tool" instead of "Vite", and combine or reorder clauses so the bit about esbuild/Rollup and the distinction that vite_rails is a build-only gem appear in separate sentences; update the sentences mentioning "Vite Ruby", "Vite", and "vite_rails" to remove the repeated leading word while keeping the same facts.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Line 157: Update the claim "Rspack support for faster builds (~20x vs
Webpack)" to match the benchmark section that states "production builds are
5–10x faster than Webpack" by replacing the ~20x figure with the 5–10x range (or
a consistent wording such as "5–10x faster than Webpack") so the comparison in
the header/content and the benchmark detail (referenced in the same document)
are consistent.
---
Duplicate comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Line 170: The "10–100x faster SSR" claim in the "Node renderer — dedicated
Node.js server for 10–100x faster SSR (replaces ExecJS)" line is unsupported;
either provide a citation/benchmark to substantiate it or soften the language.
Update the sentence in the "Node renderer" bullet: if adding data, reference a
specific benchmark or external source (include brief methodology and numbers)
and cite it inline; otherwise change the phrase to a non-numeric claim such as
"significantly faster SSR" or "substantially improved SSR performance" to remove
the unverified "10–100x" figure. Ensure the modified text and any added citation
are consistent with the surrounding Vite vs Rspack benchmark section.
---
Nitpick comments:
In `@docs/oss/getting-started/comparison-with-alternatives.md`:
- Line 70: The paragraph repeats "Vite" at the start of three sentences; reword
to vary sentence openings and improve flow by referencing "Vite Ruby" and
"vite_rails" differently—for example start the second sentence with "It" or
"This tool" instead of "Vite", and combine or reorder clauses so the bit about
esbuild/Rollup and the distinction that vite_rails is a build-only gem appear in
separate sentences; update the sentences mentioning "Vite Ruby", "Vite", and
"vite_rails" to remove the repeated leading word while keeping the same facts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7b8f4989-3099-49fa-b7f3-603f1d516d04
📒 Files selected for processing (1)
docs/oss/getting-started/comparison-with-alternatives.md
| - Built-in SSR for SEO and fast initial page loads | ||
| - No separate API layer needed — props flow directly from controllers | ||
| - Auto-bundling eliminates manual pack management | ||
| - Rspack support for faster builds (~20x vs Webpack) |
There was a problem hiding this comment.
Reconcile build speed claim with benchmark data.
This line claims "~20x vs Webpack" but Line 121 in the benchmark section shows production builds are "5–10x faster than Webpack." Use the benchmark data consistently.
📊 Proposed fix to align with benchmarks
- - Rspack support for faster builds (~20x vs Webpack)
+ - Rspack support for faster builds (5–10x vs Webpack in production)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Rspack support for faster builds (~20x vs Webpack) | |
| - Rspack support for faster builds (5–10x vs Webpack in production) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/oss/getting-started/comparison-with-alternatives.md` at line 157, Update
the claim "Rspack support for faster builds (~20x vs Webpack)" to match the
benchmark section that states "production builds are 5–10x faster than Webpack"
by replacing the ~20x figure with the 5–10x range (or a consistent wording such
as "5–10x faster than Webpack") so the comparison in the header/content and the
benchmark detail (referenced in the same document) are consistent.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bcf8edd0d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Streaming SSR | — | — | — | — | — | ✓ | | ||
| | Code splitting with SSR | — | — | N/A | — | — | ✓ | | ||
| | Auto-bundling | — | — | — | — | ✓ | ✓ | | ||
| | Bundler support | Import maps | ✓ (Vite default) | Import maps | ✓ (Vite/Rollup) | ✓ (Rspack) | ✓ (Rspack) | |
There was a problem hiding this comment.
The feature matrix currently presents react-rails bundler support as only Import maps, but this repository’s own migration guide describes react-rails apps using Shakapacker/Webpack configs (docs/oss/migrating/migrating-from-react-rails.md references upgrading to Shakapacker v7 and editing config/webpack/*). This materially skews the comparison for teams evaluating migration and bundler choices, so the cell should reflect that react-rails supports more than import maps.
Useful? React with 👍 / 👎.
| - Built-in SSR for SEO and fast initial page loads | ||
| - No separate API layer needed — props flow directly from controllers | ||
| - Auto-bundling eliminates manual pack management | ||
| - Rspack support for faster builds (~20x vs Webpack) |
There was a problem hiding this comment.
The "~20x vs Webpack" figure is inconsistent with the benchmark tables shown earlier in this same document:
- Dev startup at 10k components: Rspack 1,438 ms vs Webpack 21,444 ms → ~15x
- Production builds at 10k components: Rspack 3,466 ms vs Webpack 28,138 ms → ~8x
Either source the 20x claim or adjust to match the evidence (e.g., "3–15x depending on project size and build type").
| | 5k components | 1,724 ms | 1,075 ms | 9,278 ms | | ||
| | 10k components | 3,466 ms | 1,986 ms | 28,138 ms | | ||
|
|
||
| Vite (powered by Rolldown) produces production builds **1.4–1.7x faster** than Rspack. Both are **5–10x faster** than Webpack. |
There was a problem hiding this comment.
Stable Vite (5.x / 6.x) uses Rollup for production builds — Rolldown is still experimental as of early 2026. If rspack-contrib/performance-compare benchmarks were run against standard Vite+Rollup, calling it "Vite (powered by Rolldown)" is inaccurate and could mislead readers into expecting Rolldown-level speeds from a standard Vite install. Please verify which bundler was active during the benchmark run and update the attribution accordingly.
|
|
||
| ## Feature Comparison | ||
|
|
||
| | Feature | react-rails | Inertia.js | Hotwire / Turbo | Vite Ruby | React on Rails (OSS) | React on Rails Pro | |
There was a problem hiding this comment.
The table uses two different symbols without explaining the distinction:
N/A(Hotwire column) — seemingly "not applicable to this tool category"—(Vite Ruby column) — seemingly "not supported"
These mean different things but look similar at a glance. Consider adding a legend below the table, or normalize to one symbol (e.g., use N/A everywhere for "doesn't apply" and — only for "the tool exists in this category but doesn't support it").
|
|
||
| ### react-rails | ||
|
|
||
| [react-rails](https://github.com/reactjs/react-rails) was one of the first gems to integrate React with Rails. It provides a `react_component` view helper and basic ExecJS-based server rendering. The project is now in maintenance mode and maintained by [ShakaCode](https://www.shakacode.com/), with active feature development focused on React on Rails. It lacks support for modern React features like streaming SSR, code splitting, or React Server Components. |
There was a problem hiding this comment.
The claim that react-rails "is now in maintenance mode and maintained by ShakaCode" is significant. Is this announced on the reactjs/react-rails repo itself (e.g., in the README or a pinned issue)? Readers who cross-check will land on that repo and may find no such announcement, which could undermine the credibility of this comparison. Worth linking to wherever this is publicly documented, or coordinating the messaging with the react-rails repo before publishing.
|
Overall this is a well-structured, useful addition. All relative links resolve correctly, the CI link-checker passed, and the document openly discloses its vendor perspective on benchmarks. The four inline comments above cover the specific issues -- summarized here for visibility:
Minor suggestion: the Further Reading section would benefit from a link to rails-webpacker-react-integration-options.md, which has complementary SSR/HMR depth for Shakapacker. |
## Summary - Adds new `docs/oss/getting-started/comparison-with-alternatives.md` with a feature matrix comparing React on Rails (OSS + Pro) against react-rails, Inertia.js, and Hotwire/Turbo - Includes per-option overviews with strengths, trade-offs, and "best for" guidance - Adds a decision table for quick lookup based on project needs - Cross-links from `introduction.md`, `docs/README.md`, and the legacy `rails-webpacker-react-integration-options.md` Closes #2637 ## Test plan - [ ] Verify all internal doc links resolve correctly - [ ] Review feature matrix for factual accuracy - [ ] Confirm the doc renders correctly on the documentation site 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only changes that add new content and cross-links; risk is limited to potential inaccuracies or broken links. > > **Overview** > Adds a new OSS doc, `getting-started/comparison-with-alternatives.md`, providing a feature matrix and decision guidance comparing React on Rails (OSS/Pro) with `react-rails`, Inertia.js, and Hotwire/Turbo. > > Updates existing docs (`docs/README.md`, `oss/introduction.md`, and `building-features/rails-webpacker-react-integration-options.md`) to link readers to the new comparison page. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4b896ce. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive "Comparison with Alternatives" guide evaluating React on Rails, Inertia.js, Hotwire/Turbo, and react-rails. * Includes a detailed feature matrix, per-option overviews, migration guidance, and a decision/recommendation matrix to help choose an integration approach. * Added prominent cross-references and a top-of-page callout to the new guide from key docs and the Quick Reference. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <[email protected]>
- Adds new `docs/oss/getting-started/comparison-with-alternatives.md` with a feature matrix comparing React on Rails (OSS + Pro) against react-rails, Inertia.js, and Hotwire/Turbo - Includes per-option overviews with strengths, trade-offs, and "best for" guidance - Adds a decision table for quick lookup based on project needs - Cross-links from `introduction.md`, `docs/README.md`, and the legacy `rails-webpacker-react-integration-options.md` Closes #2637 - [ ] Verify all internal doc links resolve correctly - [ ] Review feature matrix for factual accuracy - [ ] Confirm the doc renders correctly on the documentation site 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only changes that add new content and cross-links; risk is limited to potential inaccuracies or broken links. > > **Overview** > Adds a new OSS doc, `getting-started/comparison-with-alternatives.md`, providing a feature matrix and decision guidance comparing React on Rails (OSS/Pro) with `react-rails`, Inertia.js, and Hotwire/Turbo. > > Updates existing docs (`docs/README.md`, `oss/introduction.md`, and `building-features/rails-webpacker-react-integration-options.md`) to link readers to the new comparison page. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4b896ce. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> * **Documentation** * Added a comprehensive "Comparison with Alternatives" guide evaluating React on Rails, Inertia.js, Hotwire/Turbo, and react-rails. * Includes a detailed feature matrix, per-option overviews, migration guidance, and a decision/recommendation matrix to help choose an integration approach. * Added prominent cross-references and a top-of-page callout to the new guide from key docs and the Quick Reference. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <[email protected]>
- Adds new `docs/oss/getting-started/comparison-with-alternatives.md` with a feature matrix comparing React on Rails (OSS + Pro) against react-rails, Inertia.js, and Hotwire/Turbo - Includes per-option overviews with strengths, trade-offs, and "best for" guidance - Adds a decision table for quick lookup based on project needs - Cross-links from `introduction.md`, `docs/README.md`, and the legacy `rails-webpacker-react-integration-options.md` Closes #2637 - [ ] Verify all internal doc links resolve correctly - [ ] Review feature matrix for factual accuracy - [ ] Confirm the doc renders correctly on the documentation site 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only changes that add new content and cross-links; risk is limited to potential inaccuracies or broken links. > > **Overview** > Adds a new OSS doc, `getting-started/comparison-with-alternatives.md`, providing a feature matrix and decision guidance comparing React on Rails (OSS/Pro) with `react-rails`, Inertia.js, and Hotwire/Turbo. > > Updates existing docs (`docs/README.md`, `oss/introduction.md`, and `building-features/rails-webpacker-react-integration-options.md`) to link readers to the new comparison page. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4b896ce. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> * **Documentation** * Added a comprehensive "Comparison with Alternatives" guide evaluating React on Rails, Inertia.js, Hotwire/Turbo, and react-rails. * Includes a detailed feature matrix, per-option overviews, migration guidance, and a decision/recommendation matrix to help choose an integration approach. * Added prominent cross-references and a top-of-page callout to the new guide from key docs and the Quick Reference. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <[email protected]>
1 participant
Summary
docs/oss/getting-started/comparison-with-alternatives.mdwith a feature matrix comparing React on Rails (OSS + Pro) against react-rails, Inertia.js, and Hotwire/Turbointroduction.md,docs/README.md, and the legacyrails-webpacker-react-integration-options.mdCloses #2637
Test plan
🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes that add new content and cross-links; risk is limited to potential inaccuracies or broken links.
Overview
Adds a new OSS doc,
getting-started/comparison-with-alternatives.md, providing a feature matrix and decision guidance comparing React on Rails (OSS/Pro) withreact-rails, Inertia.js, and Hotwire/Turbo.Updates existing docs (
docs/README.md,oss/introduction.md, andbuilding-features/rails-webpacker-react-integration-options.md) to link readers to the new comparison page.Written by Cursor Bugbot for commit 4b896ce. Configure here.
Summary by CodeRabbit