Ruby on Rails: 10 years later, I’m still all-in

 

 "Good design is obvious. Great design is transparent." – Joe Sparano

Back in 2013, I was working on a piece of desktop software where the graphical engine was running on Fortran code older than disco music. The newer parts were built in C and C++, with complex dependencies and manual memory management. Every night, we’d kick off the build process, and it would take a full day for all the test cases to run across platforms. It wasn’t just a job; it was an endurance test.

Then came Ruby. I still remember that day at a local Coderetreat. Coming from C and Fortran, it was like stepping into the light. No semicolons to babysit, no battling with cryptic compiler errors. It was instant feedback, like nothing I had ever experienced before. You write the code, and the code just works.

That’s when I decided I wanted to become a Ruby on Rails developer. Because it was regarded as a mostly backend framework, I’ve also had to dive into frontend frameworks like Backbone, Angular, Ember, and more recently, React. Every time, I bought into the excitement. But the romance faded quicker than my excitement at a stand-up meeting. Aside from React, all of them fell out of favor for new projects, and much of what I invested in them now feels like lost time. Rails, however, has been a constant through it all. Rails is the anti-hype.

Hotwire brings back the simplicity of sending HTML over the wire, like it’s 1999. No build steps, no JavaScript fatigue, and no 10-minute npm installs. This is not something new. It evolved from Turbolinks, which was introduced all the way back in 2012 with the release of Rails 4. I’ve watched the JavaScript world spiral into complexity, and Rails has kept me sane.

Now, we’ve got Hotwire Native, which lets you extend this simplicity into mobile development. Write once in Rails, and your app is ready for web and mobile. No need for separate stacks or specialized knowledge of iOS or Android.

Rails developers have naturally evolved into DevOps pros without breaking a sweat. Chef, Capistrano, and Puppet: all born from the same Ruby DNA that powers Rails. I’ve learned and was made to feel confident that I can not only write code, but can also deploy it and manage infrastructure. When the term DevOps started gaining popularity, I never regarded it as a distant, off-limits specialization. In the Rails world, ‘full stack’ means the complete stack—from writing code to deploying and managing infrastructure. No handoffs to someone else.

In terms of speed, a recent study showed that in specific workloads, Ruby 3 outperformed C. There’s nothing wrong with Go or Rust, but I was never forced to abandon Ruby.

Shopify scaled Rails in ways that make tech pundits clutch their microservices manifestos in horror. Instead of rushing off to dismantle their app into a million microservices written in Go, they stuck with the monolith—because hey, when you’ve got a Ferrari, you don’t swap it out for a fleet of scooters. Instead, they built tools like Packwerk and Tapioca to manage complexity, while keeping the productivity of Rails intact.

I’ve worked at companies where the rush to ship new features overshadowed the importance of fixing bugs and maintaining code quality. It’s easy for developers to blame the framework, especially when they come from other languages. This is almost always a company culture issue—lack of proper, extensive, deeply technical onboarding, ignored technical debt, and incentives to ship features over fixing bugs. Rails isn’t the culprit, it’s your company’s culture.

From rapid prototyping as a solo developer to scaling a product that serves a billion users, Rails still allows you to do both. Onwards!