Every year someone writes a “Rails is dead” post. Every year it’s wrong. I’ve been building with Rails since before most of those writers had their first dev job, and I’m still building with it today. Here’s why.
The Dead Framework That Keeps Shipping Software
Let me get the counterargument out of the way first, because it’s worth taking seriously.
Rails isn’t the hot framework. The JavaScript ecosystem got enormous and now has viable full-stack options. Go, Elixir, and Rust handle certain performance-intensive workloads better. The startup world moved toward microservices and serverless for a while (and a lot of them are quietly moving back). And yes, some Rails codebases became notorious nightmares because people abused the framework’s permissiveness.
All of that is true. None of it makes Rails a bad choice in 2025.
What Rails Actually Is
Rails is a full-stack web framework built on Ruby. It was designed with a set of strong opinions about how web applications should be structured — conventions over configuration, an integrated ORM, a testing framework built in, background job queuing, mailers, asset handling. The whole thing out of the box.
That set of opinions is what made it controversial and what makes it great. You’re not spending weeks making architectural decisions. You’re building.
The constraint is also the speed. A developer who knows Rails well can have a working, tested, deployed application in the time it takes some teams to finish their framework selection meeting.
The “Rails is Dead” Argument Is Mostly Vibes
The actual data doesn’t support the narrative. GitHub, Shopify, Basecamp, Cookpad, and Zendesk are all running on Rails at massive scale. Shopify, specifically, processes millions of requests per minute on a Rails monolith. When people say Rails can’t scale, they mean they don’t know how to scale it — which is different.
The “dead” narrative comes from the frontend JavaScript explosion, not from any actual decline in Rails’ ability to build production software. It conflates “not trendy” with “not viable.”
I build software for businesses, not for developer trend articles. My clients don’t care whether their software is built in Rails or Go — they care whether it works, whether it’s reliable, and whether future changes can be made without bringing in a specialist every time. Rails delivers on all three when used correctly.
What Rails Does Better Than the Alternatives
Speed to production. There’s no framework that gets you from zero to production faster for a typical web application. The conventions mean less decision paralysis, less boilerplate, and a well-worn path for every common pattern. Authentication, file uploads, background jobs, email — Rails has established patterns for all of it.
ActiveRecord is genuinely excellent. The ORM criticism usually comes from people who’ve seen it misused. When used well, ActiveRecord is expressive, readable, and powerful. Migrations are clean. Complex queries are manageable. The performance pitfalls (N+1 queries, missing indexes) are well-documented and easily avoided with basic discipline.
Testing culture. Rails was built with testing in mind, and the Ruby community has strong testing norms. RSpec and Minitest are both excellent. The combination means Rails codebases tend to have meaningful test coverage — which matters a lot when you need to maintain and extend software over years.
Mature ecosystem. Whatever you need to build, there’s a battle-tested gem for it. Devise for authentication. Sidekiq for background jobs. Pundit or CanCanCan for authorization. Stripe integration. PDF generation. The list goes on. You’re not solving problems from scratch; you’re assembling proven components.
Rails 7 and 8 are genuinely good. The recent releases aren’t a framework on life support. Hotwire (Turbo + Stimulus) brought productive full-stack development back without the complexity of a heavyweight JavaScript framework. Solid Queue replaced the need for Redis in many background job scenarios. Rails 8 ships with Kamal for deployment. The framework is being actively improved by people who use it in production.
When Rails Is the Right Choice
Rails makes strong sense when:
- You need a full-featured web application with a database, user accounts, background jobs, email
- You have a complex domain model that benefits from ActiveRecord’s expressiveness
- You want to move fast and maintain the ability to change direction
- You’re building something that will live for years and needs to be maintained by future developers
- You want a single developer or small team to be able to cover a lot of ground
When Rails Might Not Be the Right Choice
It’s worth being honest about the trade-offs.
If you’re building a high-performance API that does very little business logic and serves millions of requests per second with sub-millisecond latency requirements, Go or Rust might be a better fit. Rails can be fast, but it’s not going to beat a purpose-built Go service on raw throughput.
If your frontend is extremely complex and you’re already deep in a React or Next.js stack, having a separate Rails API might add unnecessary complexity. Though Rails still handles the backend well in that configuration.
If your team doesn’t know Ruby and has no interest in learning it, that’s a real operational cost. Rails doesn’t help you if nobody on the team wants to work in it.
My Take
I’ve used Rails for over a decade across dozens of projects. I’ve also used React, Node, Python/Django, Flutter, and a few others. The right tool depends on the job.
But for a typical business web application — internal tools, customer portals, data management systems, e-commerce, operational software — Rails is still one of the best choices available. It lets a developer move fast without accumulating a pile of architectural decisions that slow teams down later.
The “Rails is dead” crowd has been wrong for 15 years. I expect they’ll keep being wrong for another 15.
If you’re building something and want to talk through whether Rails is the right fit for your specific situation, let’s talk. I’d rather spend 30 minutes on that conversation than have you build on the wrong foundation.