I'm currently trying to decide what server-side language to learn and use for web development, and while it's relatively easy to get information on why x, y, or z is a good thing, it's harder to figure out the downsides to each of them.

In particular, I'm curious about what drawbacks there are to learning and/or using Ruby on Rails as opposed to any other given language/framework.

  • 5
    It made me hate ASP.NET, a lot. Which was a problem since that was my day job.
    – Jeremy
    Jun 20, 2011 at 16:32
  • 5
    Just mentioning this in a comment, in case others want to elaborate, but one thing that's both a pro and a con is that RoR can be a little too "magical" at times -- it can be hard to understand sometimes what's going on behind the scenes (and so, if you're new to web development, you'll take a lot of things for granted). Of course, this is basically true for all high-level languages, and it's also what makes them easier and faster to work with.
    – grautur
    Jun 20, 2011 at 21:09
  • 1
    FWIW if you're looking at RoR definitely look at ASP.NET MVC3 with Razor. And honestly if you like getting paid (I sure do) that's 40% of the reason I develop in ASP.NET. The other 60% is I feel it is best web platform period even if it has its pain points, which of those almost all have been summarily ended with Nuget.
    – user7550
    Jun 21, 2011 at 13:01
  • Think of RoR as a tool for CRUD apps, you can do other stuff with it, but for more general stuff other languages/frameworks are more flexible without making a mess.
    – alfa64
    Mar 5, 2012 at 1:35

10 Answers 10


Speaking from experience: The downside is that you rely on the Rails framework a bit too much. This is a great and wonderful thing if you are only ever writing simple, greenfield CRUD apps that fall squarely into the Rails "sweet spot"; your productivity will skyrocket. However, the moment you have to do something outside that sweet spot - interact with an existing database, talk to another application that doesn't have a JSON or XML API defined, implement a complicated workflow, Rails will become your enemy. It is possible to do these things with Rails, but it goes "against the grain" so you're basically on your own with figuring out how to do it as the community will usually just respond with "Don't do that, it's not the Rails way" - this results in either lost productivity or very messy code as you basically have to hack around the Rails framework.

Also, there is the unspoken downside: Everything else will seem ugly and kludgy. Once you have tasted the sweet, sweet nectar of Rails (okay, evangelizing just a bit here...) everything else is swill. Going from Rails back to PHP, or ASP.NET WebForms, or Java is like walking on a bed of nails after frolicking in a lush garden; you won't see the other languages/frameworks in the same light, and while you may still appreciate them you will secretly long for Rails' loving embrace.

  • 11
    Sounds like every other framework - the moment you need something out of the box it becomes a struggle. Jun 20, 2011 at 20:00
  • 12
    Yes, but I've found it's a little worse with Rails because the entire framework is built around the idea you'll never have a reason to need something "out of the box". Compare that to Zend for PHP or ASP.NET MVC, or Django for Python and they are a lot more flexible than Rails while still giving the benefits of a framework. That's not really a slam against Rails, though. Jun 20, 2011 at 20:09
  • 3
    But luckily RoR is not the only Ruby-based webframework. I myself prefer Sinatra + Datamapper + Haml/Sass or alternatively Sinatra + Sequel + Sequel + Haml/Sass for raw SQL experience... RoR is great compared to Java- oder .NET-based solutions. But it is a heavy-weight monster compared to other Ruby-based web-frameworks.
    – Philip
    Jun 20, 2011 at 20:23
  • 4
    I'm having a hard time determining if Wayne loves or hates RoR. Is this love/hate relationship common among most RoR devs?
    – Phil
    Jun 20, 2011 at 21:56
  • 2
    @Phil a little of Column A, a little of Column B. I love RoR, even though I don't really know a lot of it; I keep trying to learn it because it really is nice. But on the other hand I've used it in a "real world" app and it bit me on the ass when I had to go outside the box of a CRUD app that talks to a single database with 1-2 models per form, and that was it. Jun 21, 2011 at 2:24

For your first server-side language, I feel like there can be a couple problems with RoR:

  1. You're not just learning a language, you're learning a framework. I would definitely take some time to play around with plain old ruby before jumping into rails.

  2. Since it is a framework, and an 'opinionated' one at that, I feel like it would give you a very limited scope of what all is going on in the framework.

Overall Ruby on Rails can be a good starting point to get the ball rolling, but there is a lot to learn about web development you may miss out on by being too reliant on a single framework.


I've tried to learn RoR several times and my biggest problem is always trying to get the packages to work correctly and the documentation. The problem with the documentation is that it always seems to be out of date (or very basic). I got the basics from the site but beyond that everything seemed so dated (even the book I bought and ended up returning). Another thing that could be a drawback is the dependencies that some of the libraries have and how they may conflict with another as stated by Ben Coe.

Something that I thought of later and instead of make it a comment, I'll just edit my answer is this: RoR has a chance of ruining Ruby for you. I know when I tried it, it made me think that "Ruby was stupid". Then a few months later I decided to give Ruby a go and loved the language, it was the framework that made me hate the language. I haven't dabbled in it much, but when I did, I really enjoyed Sinatra. I think I got the joy most people get out of RoR out of Sinatra.

  • +1 I had the same experience. I tried to learn Ruby on Rails, but I got an error just by doing rake db:migrate. On the other hand, I found Sinatra to be much simpler and easy to understand. At any rate, I prefer to set things up my own way, and the basic structure of a rails app just seemed too complicated to me.
    – Zhehao Mao
    Jun 20, 2011 at 21:07
  • @Zhehao Mao - I'm glad to see that I'm not the only one with this experience. Although, I don't think it is complicated...as long as you think the exact same way as DHH. If you have a different type of thought process, RoR can be a pain in the rear.
    – Jetti
    Jun 20, 2011 at 21:09
  • I guess it's not that it's complicated. I suppose my problem was that every time I tried to create a rails app, nothing ever worked out of the box the way the documentation said it should.
    – Zhehao Mao
    Jun 20, 2011 at 21:12
  • I found it incredibly complicated because of that fact as well. That is also why I gave up. In order for it to be RAD it has to work. I honestly think I could've made a CRUD app in C++ faster than RoR because of all the problems I was having getting RoR up and running (a bit of an exaggeration but still...)
    – Jetti
    Jun 20, 2011 at 21:17
  • I'm not sure if you guys were reading the right docs, or why you didn't ask for help... Jun 20, 2011 at 22:49

If this is your first server-side language, it's as good as any. The thing to do is focus on one, and after you feel you've mastered it, explore others and deduce your own conclusions.

I work with RoR and ASP.NET on a daily basis, but strangely enough, I prefer the ASP.NET world, but that has more to do with personal philosophy than it has to do with the language or the architecture itself. (I'm a bit of a control freak and I personally gravitate to strongly typed languages).

Regardless, I say give it a go. RoR is a great environment to work in, but before you jump right into Rails, get comfortable with Ruby as a language. Beyond web stuff, Ruby is a pretty cool scripting language if you land up having to manage a *nix box and can save you a boatload of time.

  • 4
    +1 for control freak. I have a bit of that streak too. Not just for strong type, but also - I actually in a way like configuration (despite the verbosity), rather than conventions making assumptions for me. Jun 20, 2011 at 20:27
  • Ditto, @Bobby Tables!
    – Marlon
    Jun 20, 2011 at 21:00

As someone who learned Rails recently (as a hobby - never used it for commercial grade development) and had already worked in JEE and ASP.NET, Wayne M's answer rang very true.

Anyway, there is a subtle side to this which noone has mentioned yet, but which bothered me a bit with Rails - the strong reliance on convention over configuration.

Essentially, if you're used to "Find In Files"-driven orientation with a new code base, CoC is likely to annoy you when trying to pick up Rails. It's great for simple CRUD greenfields that are done precisely the Rails way (as Wayne M says), but for anything more unique and complicated, it'll be hard to work out what's going on if you try to work out the flow by searching for stuff in files to see how the plumbing is hooked up.

Though I think, this issue probably won't be as bad once you have a lot more experience with Rails. I can definitely see it being an issue for someone coming from oldskool Java/.NET web development who is used to a very verbose configuration flow - and is used to relying on seeing everything spelled out somewhere.

  • 1
    That bothered me a bit at first, but then it didn't anymore. It was great to be able to write a database migration to create new columns, then attach business logic to the new data with no separate mapping step. Jun 21, 2011 at 6:02
  • @kevincline How do you accomplish that in RoR? You can do it with AOP in Java and .NET world.
    – crush
    Oct 30, 2017 at 15:37
  • @crush: It's painful in Java and .NET because you have to explicitly create and map properties in the mapped class for every column in the database that the business logic uses. Adding a column means changing multiple classes. RoR does all this at run-time by convention. You modify the database schema, then just change the business logic and the presentation layer to use the new column. Oct 31, 2017 at 3:50

With me, the biggest problem with I learn my first X (in your case, X is a server-side web language/framework), it's that as soon as I see other problems, I immediately want to start applying X, even when it might not be the best option. I've gotten better at this, but it's still a strong tendency.

Ruby on Rails is a good choice to start with - there is a good community, plenty of documentation, and good tutorials. But be sure to keep the alternatives in mind, especially if you start doing more web development. RoR might be overkill for some problems, an inadequate solutions for others, and the best choice for a different set. Know it's strengths, weaknesses, and how to use the tool.


My advice would be to have a clear picture of the project that you want to complete and then just start trying to build it. As you run into problems you will eventually grab all the right tools. This approach is good because you are making decisions based off of succinct problems.

Another thing to do is buy books. Internet tutorials don't cut it in my experience; they also leave a lot of room open for distraction. When you have a book, the publishers have to make sure it provides value since they will lose money if it gets bad reviews. Spending a little money will save you a lot of time.

  • But don't forget about railscasts.com. He does an outstanding job of giving you an overview of a topic/concept in about 10 minutes. I remember spending a whole weekend trying to get Sunspot to work, then watched a 10 minute Railscast about how to implement a faceted search, & had it up and running in less than an hour. WELL worth the $9/month. Oct 24, 2013 at 20:03

I honestly can't understand those who wax poetically about what a walk in the garden Ruby-on-Rails is. I came to it as an experienced ASP.NET-MVC, Java, PHP, Python developer -- and found it to be the most horrible time-waster ever! 90 percent of the online google-answers are wrong or incomplete. Why? Has it changed that much every single year? Or is it that nobody cares about making code actually work? It took me massive amounts of time to just do simple things; far, far more than it would take me in C#/ASP.NET-MVC, for example. It certainly never took me anywhere near that long to learn my original technologies. Granted, ROR is terse. If that's important to you. But I found it rarely clear how to create code that would accomplish a task. Personally, I would rather type on a keyboard for 20 seconds to write code that definitely works, is clear and you can follow it, rather than type terse Ruby code for 2 seconds, but which never works until I am up all night searching for some way to actually make it work. It is a horrible, stinking pile of dodo. Why? Is it that open-source (as in free) code, produces no incentives to make it a quality tool? Too many script-kiddies pumping revisions and modules and bad documentation into it? I don't know. But when I was finally able to escape that first Ruby-Rails project, I swore I'd never step into that mess again!

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Nov 23, 2013 at 14:41
  • This answer is hilarious. Rails is most definitely, objectively a time saver. Your grudges against it are purely because you're new to it and expect everything to click within the first few weeks. The database migrations alone are worth switching to Rails for.
    – sergserg
    Aug 10, 2014 at 1:39

I suggest you look at indices rating the prevelance of different languages/scripts. Here is a link that might prove useful: popular professionaly used web-related languages.

This shows the relative popularity of web-related languages based on searches of online job postings.


I agree to some of the above answers about RoR, I've been developing applications with RoR for the past two years. Its really good with simple applications, CRUD (Create, Read, Update and Delete) operations works very well, its a boon for developing simple applications but is also its limitations. Though there are a lot of gems offers various advantages and ease of use, its basically it. Going out of the box will get you applications all twisted.

If you are a large team working on an application using RoR, work delegation can be hard to get away with.

  • One thing that surprised me occasionally was that lots of gems out there which seemingly appear to be independent from RoR turn out to only be used with RoR, and not in standalone. Very curious to why this is. PS: I'm not a Ruby programmer, so I might have gotten the wrong impression. But I did stumble upon this a few times. Sadly I've got no examples at the moment.
    – Htbaa
    Jun 21, 2011 at 13:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.