Ruby on Rails Pros and Cons:

Good, somewhat objective summaries of the pros and cons surrounding the Ruby on Rails platform are rare. What you do find is plenty of buzz. What is Ruby on Rails all about? Why do people love it? Why do people hate it (yes, these people really do exist)? And why does it make some people very, very afraid?

 

Due to the nature of my employment, I’ve had the opportunity to work extensively with several web application frameworks, including Ruby on Rails. I’ve outlined my first-hand experiences below. Fat-free, but loaded with sugar.

Ruby on Rails: Development

 

Pros:

• Very good OR/M – This is the best part of Rails. Saves a ton of work, and there is very little setup to be up and running (no nasty XML files, etc.)  
• You feel like you are a hippie, rebelling against the system. J  
• MVC, filters, etc. very useful  
• Ruby is a terse language (compared to more tradition c-style languages), well thought-out, and very readable  
• Lots of useful code generators  
• Deployment is a snap with Capistrano  
• Lots of interesting plug-ins and gems you can use to save time.  
• Active, friendly, helpful community.  
• Lots of good documentation  
• Built-in testing framework  
• Encourages good programming patterns  
• Built-in support for AJAX

 

Cons:

 

• Scaffolding is too basic to be very useful other than for learning and basic testing  
• Easy to do things the “wrong way” if you rely too much on your experience with older web app models. I highly recommend getting some Ruby and RoR books and immersing yourself in the culture  
• Hard to prove correctness of your code. Requires mounds of unit testing (which can easily take more time than coding the app itself).  
• Large web apps become rather unwieldy. Rails is better suited to smaller, tighter code bases. Because it uses a dynamically typed, interpreted language, risk of regression bugs in your app increases exponentially with the size of the code base. Recent advancements in VMs (JRuby, Rubinius) and IDEs (Komodo, IntelliJ, Ruby in Steel), may help alleviate some of these problems.  
• Hard to debug, step through code, etc. Again, new IDE support may help some with this, but it will be some time before it is on par with, say, ASP.NET.  
• Rails development in a Windows environment is not as well supported as on a Mac.  
• Development philosophy relies heavily on “magic” and “assumptions”. Coming back to a code base after a month or two will leave you confused until you remember everything that is going on behind the scenes.

Ruby on Rails: Deployment

 

Pros: 

• Capistrano makes deployment to multiple machines straightforward  
• Runs on inexpensive *nix boxes  
• Multiple DBMS’s supported

 

Cons:

 

• Have to keep gems, plugins, rails library all up to date and deployed along with your web app  
• Capistrano’s SSH tunnel doesn’t always work the best when deploying from a Windows box  
• You will be needing multiple servers earlier than you might expect. This obviously complicates deployment, but Capistrano is a big help there.  
• When the app or server crashes, Mongrel & co. doesn’t (reliably) automatically restart (mod_rails AKA Passenger may be more reliable, but it is still fairly new and not as well tested).

 Ruby on Rails: Scaling

 

Pros

 

• Runs on inexpensive *nix boxes or you can use a VPS cluster  
• Capistrano designed with clusters in mind

 

Cons

 

• You have to use clusters to handle even moderate traffic.  
• Database can quickly become the bottleneck (this is what happened to twitter). No built-in support for multiple DB backends (shards, etc). ORM is not threadsafe.  
• Eats up tons of RAM.  
• Lots of CPU time spent, esp. in the OR/M layer. Much of this is due to heavy use of reflection. Rails 2.0 uses caching to improve this considerably, but can still be slow  
• Rendering XML for REST/SOAP is very slow if you go through the old web services layer. In my tests, C#/WCF was at least 5x faster. Using the integrated 2.x REST features is much faster – on par with .NET when using a properly-tuned stack (not taking database access into account).  
• Ruby is one of the slowest dynamic languages known to man. Ruby 1.9 is doing a lot to improve this, but statically-typed languages will always be faster. Depending on your workload, this may not matter.  
• Page and partials caching can speed things up a lot, but is a pain to maintain when you make changes to your code  
• Serious problems with piping files greater than a couple MB (i.e., PDFs, downloading a purchased product). I had to use PHP because Rails would crash every time.  
• You have to use something else for serving static files, such as images and CSS. I highly recommend Nginx. Also makes a great proxy to Mongrel. 

 Ruby on Rails: The Bottom Line


Rails is a fun framework that takes a lot of the drudgery out of web programming. However, it’s lack of really great IDE support and static code analysis makes large apps difficult to maintain. There are also some serious scaling issues, even after recent developments speeding up rails 2x or so. I would recommend this for smaller projects with low to medium traffic loads. For very small projects, lighter MVC frameworks also based on Ruby would probably be more appropriate. If you are creating a web service that has to be SOAP or has to do a lot of computations or extensive data manipulation, I would stay away from Ruby altogether.

That being said, the critical weaknesses of the language and the framework (e.g., performance) are actively being addressed. So, even if you don’t choose to use Rails today, you would be quite foolish not to keep it on your radar.