Ruby on Rails is back—not because it left, but because the alternatives got expensive in ways money can’t easily fix. After years of React ecosystem sprawl, React Server Component confusion, and Vercel pricing shocks, senior engineers are rediscovering what Rails always offered: a complete, opinionated stack that lets one developer build what used to require a team.
The evidence is specific. Rails World 2024 in Toronto sold out 1,000 tickets in under twenty minutes, drawing attendees from 57 countries. RubyGems downloads hit 4.15 billion in a single month in April 2025—a 51% year-over-year increase.1 These aren’t signs of a framework on life support. They’re signs of one whose moment has come back around.
What Caused the JavaScript Fatigue Breaking Point?
The shift didn’t happen overnight. It accumulated across three years of compounding complexity in the React ecosystem.
The 2025 State of JavaScript survey, drawing roughly 12,000 respondents, put numbers to what developers had been feeling qualitatively. React’s usage remains dominant at 83%, but its admiration score has dropped to just 52.1%—meaning nearly half of React developers would not choose it again if starting fresh.2 Next.js admiration fares slightly worse at 17% dissatisfied, with developer feedback using phrases like “Next complexity has gotten absurd.”
The specific flash points:
React Server Components introduced a new mental model that even experienced React developers struggle to apply correctly. Mark Erikson, maintainer of Redux and one of React’s most articulate community voices, described the ecosystem as feeling “complicated”—the framework no longer simple by default. Context API limitations, testing gaps, bundler compatibility issues, and library breakage followed RSC adoption across the ecosystem.
Vercel ecosystem capture became a recurring concern. The architectural gravity of Next.js steadily pulls applications toward Vercel-specific features—Edge Runtime, ISR, App Router conventions, streaming UI patterns—that work cleanly on Vercel but require significant adaptation elsewhere. Moderately successful SaaS applications routinely encounter Vercel invoices of $500–2,000 per month.
The assembly tax. Building a production-ready React application requires stitching together a routing library, a state management layer, a data-fetching strategy, an authentication solution, a job queue, a caching layer, and a deployment pipeline—each with independent maintenance cycles, breaking changes, and community consensus that shifts over time. A developer making technology decisions in 2026 is inheriting the accumulated choices of all those projects.
Alex Russell, on the Microsoft Edge performance team, argued that “using React in 2025 makes you a bad person” due to performance overhead—React ships ~100KB of JavaScript by default, compared to Preact’s 3–4KB drop-in alternative.3 When Microsoft rebuilt portions of Edge away from React, they measured approximately 40% performance improvements.
What Rails Actually Is in 2026
Rails 8, released November 7, 2024, is not a framework frozen in the choices of 2005. It is an actively maintained, aggressively opinionated full-stack platform that has absorbed the lessons of two decades of web development.
The release’s central argument is captured in its tagline: No PaaS Required. Rails 8 ships with:
Kamal 2: A deployment tool that takes a fresh Linux server and turns it into a production application in under two minutes with a single kamal setup command. No Heroku. No Fly.io. No AWS App Runner. A $6/month VPS and a domain name are sufficient infrastructure for launching a production application.
The Solid Trifecta: Three new adapters—Solid Queue, Solid Cache, and Solid Cable—replace Redis for background jobs, HTML fragment caching, and WebSocket pub/sub respectively, all using a standard SQL database. Solid Queue processes 20 million jobs per day for HEY, the 37signals email service.4 Solid Cache stores 10 terabytes of cached data for Basecamp on disk—vastly more capacity and at lower cost than RAM-based Redis.
Import Maps by default: Rails 8’s #NOBUILD philosophy means a new application ships zero Node.js toolchain. No Webpack. No Vite (unless you opt in). Browser-native ES modules handle JavaScript loading directly. For applications that don’t need complex client-side state, this eliminates an entire category of maintenance overhead.
Authentication generator: bin/rails generate authentication produces complete Session and User models with password reset flows—first-class citizen, not an afterthought.
Hotwire: The Frontend Solution You Haven’t Looked At
The most underexamined part of modern Rails is Hotwire—a frontend approach that shipped as the Rails default with Rails 7 in December 2021 and has matured significantly since.
Hotwire has three components:
Turbo eliminates the need for React entirely for the majority of web application interaction. Turbo Drive intercepts link clicks and form submissions, replacing only the <body> of the page without a full reload—delivering SPA-like navigation speed from a server-rendered application. Turbo Frames allow targeted partial page updates. Turbo Streams deliver real-time server-push updates over WebSockets, enabling live notifications, counters, and collaborative UI without a JavaScript state management layer.
A feature that would require React + Redux + WebSocket + a streaming state-sync library can be expressed in a Rails controller response like this:
app/controllers/notifications_controller.rb
def create @notification = current_user.notifications.create!(notification_params)
respond_to do |format| format.turbo_stream do render turbo_stream: [ turbo_stream.prepend(“notifications”, @notification), turbo_stream.update(“notification_count”, current_user.notifications.unread.count) ] end end end
Two DOM elements update in real time from a single controller action. No client-side state. No WebSocket handler. No Redux slice.
Stimulus handles targeted DOM behavior using data-controller attributes—dropdowns, modals, form validation—without taking ownership of rendering. It augments HTML rather than replacing it.
Hotwire Native enables hybrid iOS and Android applications from the same Rails codebase. Bram Jetten, who built scheduling SaaS PlanGo to €1M ARR as a solo developer, used Hotwire Native to ship mobile apps with 100,000+ yearly downloads—from the same 36,170 lines of Ruby that powers the web application.5
Rails vs. React/Next.js: A Direct Comparison
| Dimension | Rails 8 + Hotwire | React + Next.js |
|---|---|---|
| Initial setup | rails new app — zero Node.js toolchain | 10+ config decisions before writing code |
| Deployment | Any VPS via Kamal 2 | Optimized for Vercel; self-hosting complex |
| Real-time features | Turbo Streams + Action Cable | React + WebSocket + state sync library |
| Background jobs | Solid Queue (no Redis) | External queue (Sidekiq, BullMQ, etc.) |
| Authentication | Built-in generator | Auth.js, Clerk, custom—separate decision |
| Mobile | Hotwire Native (hybrid) | React Native (near-native) |
| AI code generation | Strong conventions, coherent full-stack output | Dense training data, UI-heavy output |
| Team size sweet spot | 1–8 engineers | 5–50+ engineers |
| Job market | ~9,000 global listings | Dominant, ~200,000+ listings |
| Scale ceiling | Shopify: 80M req/min on Black Friday | Facebook, Netflix, enterprise |
| Monthly infrastructure cost (small SaaS) | ~$20–50 (VPS) | $200–2,000+ (Vercel + Redis + workers) |
The Numbers: Rails at Scale
The “Rails doesn’t scale” objection is two decades stale. The current evidence:
Shopify runs the largest Rails application in the world. Black Friday 2024—running a prerelease of YJIT 3.4—handled over 80 million requests per minute with no degradation.6 YJIT (the in-process JIT compiler developed by Shopify and shipped as Ruby default) delivers a 92% speed improvement over the CRuby interpreter on representative benchmarks, with version-over-version gains of 5–7% each release cycle.
GitHub operates on approximately 2 million lines of Ruby, deploys 20 times daily, and runs automated Rails upgrades weekly.
Intercom processes 150,000 HTTPS requests per second and 50,000 background jobs per second from a 2 million-line Rails monolith.
Lago, an open-source billing infrastructure company processing millions of API calls per day, chose Rails for their core because it was “the fastest way we could build an API product.” Their architecture is explicitly polyglot: Rails handles API and billing logic; Go handles high I/O concurrency; Rust handles CPU-intensive processing.7 This is not Rails failing—it’s engineering discipline applied to the right tool for each layer.
AI-Assisted Development: The Surprising Rails Advantage
84% of professional developers now use or plan to use AI coding assistants, according to the Stack Overflow 2025 survey.8 The effect on framework selection is underappreciated.
Rails’ strict conventions give AI tools a predictable mental model. Every Rails application has identical structure. LLMs trained on GitHub data have internalized where models, controllers, views, jobs, and mailers live—and what they contain. When you ask an AI assistant to implement a feature in Rails, it can generate routes, model, controller, views, and tests in a single coherent pass, because Rails has already made the structural decisions.
React wins on training data density—AI tools have seen more React examples, and the React/TypeScript/Tailwind/shadcn stack is the dominant output when asking an LLM to build UI. But React’s architectural freedom works against AI generation at the application level: there are too many valid approaches to state management, data fetching, and component structure, producing suggestions that don’t cohere with each other.
The practical distinction: AI generates better full-stack application scaffolding in Rails. It generates better UI components in React. For greenfield full-stack applications built by small teams with AI assistance, this is a meaningful tilt toward Rails.
The Honest Case Against Rails
The talent pool is smaller. React appears in 44.7% of Stack Overflow survey responses. Rails appears in 5.9%. If you’re building a team that will grow beyond 10 engineers, hiring into Rails requires deliberate recruiting strategy and a willingness to train.
The mobile story is hybrid, not native. Hotwire Native produces functional hybrid apps with low overhead. React Native and Flutter produce more performant native-feeling experiences at the cost of a separate codebase and team.
Community governance issues surfaced in 2025. DHH’s public controversies sparked an open letter—“Plan Vert”—calling for a Rails fork, signed by notable figures including Jeff Atwood (Stack Overflow co-founder), Tim Bray, and Eugen Rochko (Mastodon creator). Mike Perham withdrew Sidekiq’s sponsorship from Ruby Central in protest. The fork did not materialize, but the episode represents real community tension that hasn’t fully resolved.
Rails World 2025 was smaller than 2024. The 2025 conference drew fewer attendees than the sold-out 2024 event—a data point that cuts against pure resurgence narratives.9
The strongest version of the Rails case is not “Rails is better than React.” It is more specific: for a team of one to eight engineers building a web application where server-rendered HTML handles 90% of interaction needs, Rails in 2026 delivers faster initial development, lower infrastructure costs, and higher architectural coherence than assembling a React-based stack from scratch.
What the Pattern Suggests
The ZIRP era funded the organizational growth that justified architectural complexity. Large engineering teams could maintain separate React frontend and Rails/Node/Go API backend codebases. The tooling, the specialization, the hiring all made sense in that context.
That context has changed. Engineering teams are smaller. Infrastructure costs are scrutinized. The “one-person framework” that DHH has promoted since Rails’ inception is now a competitive advantage rather than a throwback.
The developers returning to Rails in 2026 aren’t nostalgic. They’re running cost-benefit analysis and arriving at the same conclusion DHH articulated at Rails World 2024: “While everyone seems resigned to slice the expertise of web development into ever thinner specialties, Rails is doubling down on the one-developer framework, the full stack, and the compression of complexity.”
That compression of complexity has always been Rails’ core proposition. In 2026, the market is finally priced to value it again.
Frequently Asked Questions
Q: Is Rails actually experiencing a comeback in 2026, or is this wishful thinking? A: The evidence is mixed but net positive. RubyGems downloads grew 51% year-over-year in 2025, Rails World sold out immediately, and job listings remain strong. However, new repository creation still skews heavily toward JavaScript/TypeScript. Rails is consolidating a loyal professional base, not capturing new developer mindshare at the same rate as JavaScript frameworks.
Q: How does Hotwire compare to React for building interactive UIs? A: Hotwire handles server-rendered partial updates, real-time streams, and DOM-behavior augmentation well—covering roughly 80-90% of typical web application interaction patterns with significantly less code. For complex client-side state (interactive editors, real-time collaborative tools, data visualization dashboards), React’s component model is more expressive. The distinction is not capability but the category of application.
Q: Does Rails scale to production traffic? A: Shopify processes 80 million requests per minute on Rails during Black Friday peak load. GitHub, Intercom, and Basecamp run at enterprise scale on Rails. Ruby’s YJIT JIT compiler delivers 92% speedup over the baseline interpreter. The scaling constraint is CRuby’s GVL limiting CPU parallelism—addressed through horizontal scaling and polyglot architectures for compute-heavy workloads.
Q: Can a small team use Rails and AI coding assistants effectively together? A: Rails’ strict conventions give AI tools excellent context for generating coherent full-stack features—routes, models, controllers, views, and tests in a single pass. The tradeoff is that React dominates AI training data for UI components. For full-stack greenfield applications, the combination of Rails conventions and AI assistance is particularly productive.
Q: What happened to the “Plan Vert” Rails fork proposal? A: The 2025 open letter calling for a governance-independent Rails fork, signed by Jeff Atwood, Tim Bray, and others, did not result in an active fork. The Rails framework itself is maintained by the Rails core team and remains actively developed—Rails 8.1 shipped in October 2025 with 500 contributors and 2,500 commits. The governance concern is real but has not fractured the technical project.
Footnotes
-
RubyGems monthly download statistics, April 2025. Reported via Ruby Central infrastructure. ↩
-
State of JavaScript Survey 2025, ~12,000 respondents. Published February 2026. https://stateofjs.com ↩
-
Allen Pike, “JavaScript Fatigue Strikes Back,” allenpike.com, 2025. ↩
-
DHH, Rails 8.0 release announcement, rubyonrails.org, November 7, 2024. ↩
-
Bram Jetten, “The One-Person Framework in Practice,” bramjetten.dev, 2024. ↩
-
Shopify Engineering via Rails at Scale blog, YJIT 3.4 announcement, January 2025. ↩
-
Lago Engineering, “Why We Still Build with Ruby in 2025,” getlago.com. ↩
-
Stack Overflow Developer Survey 2025, 49,000+ respondents from 177 countries. ↩
-
Andy Croll, Rails World 2025 recap, andycroll.com. ↩