July 2004.
A guy named DHH pulls a framework out of a project management tool called Basecamp and calls it Ruby on Rails. Nobody in that room could have guessed it would still be powering production apps 22 years later.
We’ve been watching Rails long enough to know about "Rails is dead" trend on Hacker News more times than we can count.
Every July, we find ourselves looking back at how Rails has evolved. Not out of nostalgia, but because its history tells you something important: Rails has never been afraid to rethink itself before it had to.
The releases that actually mattered:
- Rails 3 — merged with Merb, went modular instead of monolithic-by-force
- Rails 4 — Turbolinks, an early bet that not every app needs a heavy JS framework
- Rails 5 — Action Cable, making real-time features first-class instead of bolted on
- Rails 6 — Webpacker and multi-database support, right as "scale" stopped meaning one big Postgres instance
- Rails 7 — killed the Node dependency with import maps, doubled down on Hotwire
- Rails 8 — Kamal for deployment, Solid Queue and Solid Cache replacing Redis for a lot of workloads, auth generators that used to mean reaching for Devise on day one
And as Rails 7.2 nears the end of its support window, Rails 8 is already carrying that evolution forward.
What resonates every time we look at history: Rails didn't survive by chasing hype. It survived by paying attention to the problems developers actually faced, from deployment and real-time UX to background jobs and authentication, and addressing them release after release.
"Convention over configuration" was never just a slogan. It was a promise that someone already fought through the hard decisions so you don't have to relitigate them on every new project.
Twenty-two years is a long time in this industry. Most frameworks don't make it five. Rails made it by staying boring where it counts and bold where it matters.
Happy birthday, Rails.
What Rails release changed how you build? Drop yours below.
Top comments (1)
I particularly appreciate how the article highlights Rails' ability to evolve by rethinking itself, as seen in releases like Rails 3, which merged with Merb and adopted a modular approach, and Rails 7, which eliminated the Node dependency with import maps. The emphasis on addressing real-world problems, such as deployment and authentication, has been a key factor in Rails' longevity. The convention over configuration principle has indeed been a promise that has saved developers from relitigating hard decisions on every new project. What I find interesting is how Rails has managed to strike a balance between staying true to its core principles and innovating to meet the changing needs of developers - how do you think this balance will be maintained in future releases, especially with the introduction of new features like Kamal for deployment?