As always, obviously the answer is "use the right tools for the job at hand". But there is a little more to it. The more assumptions your framework makes, the

As always, obviously the answer is "use the right tools for the job at hand". But there is a little more to it. The more assumptions your framework makes, the less free your are to implement what you have in mind. Meaning: you'll not be able to deliver exactly what your clients want. I prefer an environment with a good balance between assumptions and turnkey-solutions. So that I don't have to write all that silly HTTP, database and template handling from scratch, everytime, but at the same time makes no assumptions about the implementation. Rails (or Django, or YII, or any more such frameworks) have been architectured around that notion. The notion to keep out of your way when it comes to how things should look (sidenote: I remember the Drupal-days where you had sidebar-right and sidebar-left hardcoded into the core!), or how they should behave. Drupal does not offer that freedom. Not even with 20+ modules is it possible to have exactly that login/invitation-workflow that many clients demand. Simply because it makes a lot of assumptions about the login-workflow. This is why I (and I have been eating grass on both sides of the fence for over 5 years) know, for sure, that for me and my projects, Rails is the best choice. Had I not invested so much in learning Ruby, Rails and its community, I would have gone for Python/Django, as that community and filosophy fits even better with my workflow. But, Rails is great. Not as a fanboy, but as someone who has developed Rails, Symfony, Cake, fromscratch, Wordpress, and lots, lots of Drupal-systems over the year. There really are lots of good cases where Drupal is the best choice, certainly. But these are not my (favorite) cases.