Is Ruby on Rails Still Relevant?

Back in 2005 David Heinemeier Hansson demonstrated “How to build a blog engine in 15 minutes with Ruby on Rails” presentation and it influenced huge changes in approaches to the web development of 2000s.

Ruby on Rails was the thing all the trendy software engineers loved back in 2007-2009. It was still very viable production option in 2010-2012, before falling out of fashion.

Nowadays, there are lots of existing applications in the world, that were built using Ruby on Rails and there are much more RoR jobs available than during its heyday.

But is Ruby on Rails relevant for the new projects nowadays? Well, it depnds…

TL;DR⌗

I hope you’d like to read the whole article and dig in the details. But in case you’re very busy and want just a quick answer - here is a quick self-survey to check if RoR is suitable for you.

1. Do your team have Ruby on Rails experience already?
2. Are you going to build a monolithic app?
3. Are you going to use classic RDBMS like MySQL or Postgres?
4. Are you going to output mostly server-rendered HTML over HTTP?
5. Would it be okay if the HTTP response speed is not great (over 100ms)?
6. Would it be okay if every app instance would consume hundres of megabytes of RAM?
7. Would your business logic be relatively easy and consist mostly of CRUD operations?
8. Would it be okay to sacrifice post-lunch development speed for the quickest time to market right now?
9. Do your team prefers using programmer text editors over IDEs?
10. Do you expect having little to none background tasks?

If you answered “yes” to all 10 questions - congratulations! Ruby on Rails and your project is a match made in heaven! You can stop reading now. If you answered “no” to the 2-3 question - most probably Rails would be fine for you, but better read the whole article. If you answered “no” to more than 3 questions - I really doubt Ruby on Rails is the best choice for you.

Now let’s dig deeper into Rails history, capabilities and shortcomings.

Why did Ruby on Rails fall out of fashion?⌗

This is 80s fashion. If you dress like that to the retro party - you’d be amazing! Dress like that daily and people around you would think you’re a weirdo with a style.

Ruby on Rails is the product with the vibe of late 2000s and it proudly denies most of the technical revolutions that happened afterwards. I’m writing this in 2022 and in 2022 using Ruby on Rails for new products feels like wearing that clothing, that was fashionable decades ago… Is it good or bad? You decide.

Late 2000s was an era of “Web 2.0” - lots of user-generated content, social networks of all sorts, rounded corners in web design, mainstream adoption of AJAX.

This is how the popular web apps looked in the late 2000s. Back then all the apps were moving from desktop to web, every app generated HTML on the server and some of them dynamically updated it with JavaScript and more HTML or JSON from the server. Nearly all users consumed that content from their desktop PCs and laptops.

But nowadays the world and the technologies are very different!

First, the smartphone revolution happened. Nowadays mobile apps are the first class citizens, as much as a web browsers.

Second, the Single Page Application revolution happened with the huge jump in complexity and capabilities of web technologies. Like it or not, but web frontends became much more complex and in response to this Angular, React and Vue emerged and became the default choices as a Javascript UI libraries, not jQuery or Prototype.

Third, the containerization and cloud revolutions happened. Particularly Docker became the mainstream medium for deploying (and developing sometimes) server applications. Service orchestrator environments like Kubernetes and Nomad are extremely popular nowadays.

Fourth, the microservices revolution happened. Again you could love it or hate it, but the monolithic app design is not an ultimate default choice for new apps anymore.

Fifth, the NoSQL revolution. General purpose SQL databases are not always the default anymore. Nowadays document database like MongoDB are as popular as the SQL ones. Moreover, a plethora of non-generic databases (Couchbase, Cassandra, Aerospike, Clickhouse) became much more popular when you need easy scaling out of the box, higher performance or focus on data warehousing. Also, every major cloud provider promotes own proprietary database solutions today.

What makes Ruby on Rails stil awesome?⌗

RoR feels like a framework built with a specific kinds of projects and ideology in mind.

The approach is pretty straightforward. You have a business idea, Ruby on Rails is the tool to implement your idea into a minimum viable product, while having shortest possible time to market. It is just the idea, so high chances after the launch you’d have to pivot or abandon the idea altogether. The faster and cheaper it would happen - the better.

Rails allows you to build RESTful JSON APIs or WebSocket APIs… but its core functionality is based around building full stack server-rendered web apps. Having modern Single Page Applications with appropriate JS frameworks is nice for complex UIs, but not the fastest thing to develop! Having a single engineer doing both backend and frontend stuff within a single application is definitely the fastest: no communication overhead, no context switching.

There are tons of external tools and libraries for Rails, allowing you to cut corners while bringing the product to market. You need authentication and authorization? Take Devise, Pundit or other libraries. Need an admin area for a couple people? Take semi-automatic database admin tool like Administrate. All those tools are not flexible, but who cares if you just need to validate the idea?

Rails has a state of art ORM. It is both very powerful and easy to use due to Ruby’s metaprogramming capabilities. You’d be passing lazy-loaded database objects within all the architecture layers, which could easilly decrease the performance… But again who cares about the performance when you’re just bringing product to market?..

Need to execute background jobs occasionally? No problem - Rails has built-in adapters for tools like Sidekiq or Resque. Things become ugly when you need something more complicated with thousands of recurring background jobs each hour… But most probably it is not your case, when you’re just shooting for MVP.

Concerned about the hosting and deployment procedures? Just host your Rails app with Heroku or anything similar. Minimum engineering efforts required. The hosting itself would be much more expensive, than anything more generic, but it is definitely not a problem when you have just a few Rails app instances and a MySQL or Postgres instance.

Concerned about organizing business logic? Just put it as a methods of your models. Over time with increasing the complexity of the logic this approach would make the code hard to maintain, but it is not of your concern in the scope of MVP.

As much as I enjoy modern .NET or Golang and VueJS or React, I realize the simplistic MVPs with those technologies would take months to build, while with Rails you could accomplish it in weeks.

What’s wrong with Ruby on Rails?⌗

From what was described above it is clear, that Rails is geared towards old-school full stack web development, which is especially beneficial for a prototype kind of projects. The further your project stands from an old-school full-stack MVC prototype - the more Rails would stand in your way instead of helping you.

Ruby was always a very niche language: very expressive and helpful as a medium for DSLs, but with terrible performance and heavy resource usage. So is Rails.

All the development speed you get from Rails is not free. Basically you start fast and increase the technical debt over time. Within months or years of it piling up, it would either slow down the development dramatically or would require you to hire more and more people to offset that slow progress. This is a godsend if you’re a consultancy, but might be a problem when you’re paying for the development from your pocket.

Want to use gRPC or GraphQL instead of RESTful HTML/JSON? Maybe, want to use MongoDB or Couchbase instead of Postgres? Well, you could do it of course, but you’ll loose a lot of perks that Rails give you.

Want to make Rails-based microservices? It is possible, but you’d have a huge overhead, since Rails is intended as a monolith.

Want to use Rails services inside Kubernetes, Nomad or similar environment together with service discovery? Again you could do it, but it would not be as straightforward and easy as something more modern or just more flexible. Same for adding extra observability tools, 12-Factor and other devops approaches.

Planning on having framework-independent architecture like the Hexagonal one? Again you can do it, but Rails is very opinionated and alternative architecture with it would be hard to implement.

Want to use IDEs effectively with its automatic refactoring, autosuggestions, errors highlighting? Sorry, neither Ruby nor Rails were built with IDEs in mind. Either you have amazing metaprogramming and dynamic programming capabilities or good IDE support.

Data validation is a part of the model and partially controller layers in Rails and not very flexible. Once you’ll need it more complex - Rails would be standing in your way.

Rails works great with Sidekiq and allows you having background jobs, including recurrent ones. However things go sour once you need something more complex like an Actor Model or conditional scheduling.

No conclusions, just summary⌗

Both Ruby and Rails were always very niche technologies. Due to its capabilities, the state of technology of its time and great marketing Rails became very popular in the late 2000s and punched above its weight.

Over time Rails became even more capable and stable, but the hype cycle ended and the world moved forward. The people behind Rails decided no to chase modern trends, but instead focus on the small niche where they were always great: building minimum viable products.

That’s why I love Rails so much and absolutely hate that goddamn Rails!