Rails is a well known framework to build modern web applications. It is popular and is used successfully by many projects. Just because someone else used and likes Rails, should you?

In this article I explore the question of “When should I use Rails to build my web app?” because I think there are cases where Rails is not the appropriate technology choice.

I say this as a developer who believes in making pragmatic technology choices. If you have a nail, you use a hammer. If you have a screw, you use a screwdriver. If you have a web app, Rails isn’t always the best tool. Sometimes it is.

What Rails Is Good At

Rails is great at standing up something useful fast. I would say that is Rails’ greatest strength. It is pretty easy to build a lot of common functionality fast in Rails.

Rails also has the advantage of popularity. Popularity means that Rails has better documentation, books, blog posts, training, and videos available than many other frameworks do. It is easier to find libraries that work well with Rails. If you have a bug or problem in your app, it is easy to find a solution for it on Google.

The other advantage of Rails is that it’s popular enough that you can find many well trained developers that can build software with Rails. That is one reason many startup companies use Rails, the combination of developer availability and development speed is very compelling if you are a new company.

What Rails Is Bad At

In my experience, Rails is bad at the things the Rails team doesn’t care much about. What I mean is, Rails’ team is opinionated and they care a lot about solving their own problems. If they haven’t encountered the same problem, they are less likely to empathize with your problems.

What this means for you is Rails is designed to solve a certain class of problems well, and then it is up to you to figure out the rest. If your needs align with Rails, then it’s fantastic. When they don’t, it isn’t.

So, if you need the highest levels of performance, Rails isn’t going to help you. If you are rabid about reliability or durability, Rails doesn’t care. It is up to you to design your server architecture to handle those details. If you have significant logic and data structure complexity, Rails isn’t going to do much for you beyond MVC.

Rails is also not a full blown e-commerce or content management system. You can build those features on top of Rails, or use systems like Spree or Alchemy to have that functionality, but out of the box Rails doesn’t do any of that for you.

Also, Rails is okay at building small things, but many developers would call it overkill for a simple application. Say you had a database that you wanted to have a few API endpoints in front of. I would probably build that in Sinatra before I would use Rails. In many cases you just don’t need the added complexity of Rails.

When Rails Falls Down For Teams

The place where Rails really falls over is when significant complexity or performance requirements hit your application and the Rails MVC structure no longer makes sense.

There is a point in every application where it is a simple thing. Take twitter for example. Creating the most basic version of twitter takes an afternoon in Rails.

What happens when you want to add pictures, videos, retweets, likes, favorites, and ads to the feed? What happens when you have four or five different user account types with different UI’s and more complex data models? How do you do analytics or data storage or archiving or hashtags or search and so on?

At some point twitter is no longer a couple tables in a database. It becomes a monolithic web app serving multiple user types, has dozens of models, dozens of controllers, and potentially hundreds of views.

The complexity of such an application means that things become hard to develop and the general approach is to move outside of Rails to continue forward.

Complexity in a decent sized application moves beyond the basic model, view, controller structure and Rails isn’t designed for that. Rails gives you a lot of best practices for a Rails MVC app. That’s it.

If performance is a critical concern, Rails is not a performance champion. It delivers good performance and scales well to a large user base, but some applications require a performance level that Rails isn’t going to give you.

Part of that is Ruby’s fault. It’s not the fastest language. Part of that is Rails’ fault. It’s not the fastest framework.

Now, the point that Rails performance becomes a pain point is different for every application. With good design and sensible approaches to common scaling issues, Rails can handle hundreds of thousands if not millions of users to your web app on reasonably priced hardware. Without some thought put towards performance, Rails performance can be a lot worse than you would expect.

Rails is great for some apps, but once your application has significant complexity or performance needs, Rails is going to be a source of frustration.

Where Rails Fits Best

My belief is that in many cases Rails makes a lot of the right tradeoffs for what it is trying to achieve. By following a set of conventions, you don’t spend so much time reinventing the wheel. It increases developer productivity compared to other tools like Java EE.

The best fit for Rails is a new application with low to moderate complexity, where rapid development is prioritized above stability or performance. A new software as a service application might be a great candidate for Rails in the first year or two of its life.

Another great fit is when you need an e-commerce system, but you have custom needs that are specific to your business. Building on top of Spree and Rails makes a lot of sense in that scenario as compared to say Magento or Shopify.

At some point if you are lucky enough to have a really successful web application, full of features, making you money hand over fist, Rails might not be a good fit for your needs.

That is not in any way a knock on Rails. Rather, it is just an understanding of the reality of software development. At some point many tools stop making sense and we need to use a different tool to do the job.

Requirements change over time, your framework needs will too.

For the many simple applications, I would probably reach for Sinatra in Ruby or even plain old PHP. For something of low to moderate complexity, Rails is a fantastic choice.

At the highest levels of complexity or performance, you will need something more customized to your specific requirements. In those cases, Rails might be a great fit for some parts of your system, but not all parts.


P.S. I unpack more ideas in Creative Genius