I've been using Ruby on Rails for at least 18 months, and it is an amazing application framework. However, it's not suitable for all projects. For one thing, hosting is much more demanding and less mature. If you don't have at least $50/month for a VPS or equivalent you are not going to get the reliability you can get with PHP relatively cheaply.
The other thing is that Rails is geared primarily towards applications. In terms of arbitrary functionality, Rails is really the best thing going. It gives the web app developer tools to create raw web interfaces very very efficiently. Probably more efficiently than is even possible in PHP due to Ruby's dynamic language features like method_missing? and dynamic class modification.
However, most websites aren't applications. The majority of clients don't have the budget to build something from scratch (even if Rails makes that development 5 times faster). Content management is one of the most common needs of clients. Drupal's node-based architecture is not as flexible as a generic MVC framework, but its a more specific solution to an extremely common problem. Given the range of modules for Drupal, you can set up full-featured sites right out of the box.
However, all this built-in functionality exacts a cost in complexity. Drupal is an amazing architecure, but it can never be as easy to customize as Rails without fundamentally changing what it is. Rails, likewise, can't really implement anything like a Drupal module. Rails has Plugins, Components, Engines, and Code Generators, but none of these things work as seamlessly as Drupal modules, because Rails doesn't dictate any architecture beyond MVC and some basic hooks on that theme.
I'm still fairly new to Drupal, so my understanding doesn't run deep enough to outline where Drupal could steal ideas from Rails effectively (I know there are plenty). But I do know that Drupal is providing an indispensable tool for probably half of my clients, whereas Rails is a better fit for 25%, with the other 25% better off with a variety of other more lightweight tools that I use. I don't see them really competing at all.
Comments
You are right, they are very different
So one aim of this group should be to make that fact clearer. Instead of presenting RoR and Drupal as opponents (Drupal vs RoR) we should try to find where both differ and when one of two is better suited for a project.
http://www.webschuur.com | http://bler.webschuur.com
Drupal versus Ruby on Rails
Good thinking!
As I approach my project, which has portal and networking functions, I'm not quite sure whether to implement Drupal, Rails or Drupal with Rails. Of course it depends on specifics, but that's my point and Ben Kessels too. They both have advantages, why not elaborate on the strengths and weakness, where one is totally unique, where another is weak.
Has anyone gone beyond the religion from either camp to come up with an "objective" or tabled evaluation?
panama
http://www.webfaction.com/
http://www.webfaction.com/ has some good prices on hosting for web applications. On the time issue when it comes to the deploying a website; I suspect that if a Drupal site requires a lot of customisation (I've done a few) the deployment time actally comes pretty close if you are building from scratch with a framework such as Rails or Django. Where Drupal shines is the CMS tools. If the user/client will want to manage the site themselves Drupal is a better choice for speedy deployment.
slightly off topic... method_missing?
I don't know ruby, but how is method_missing different from PHP 5's __call() magic method? Seems to get the same job done.
I think, with PHP6 not that far down the line, it's time for drupal to start considering using some of PHP's OOP language features.
main ruby's advantage is not
main ruby's advantage is not in functionality but in simplicity. all those conventions around constant/class/variable namings, interpretator required indentations like in python and so on makes code very readable. also flexibility is an argument here - with rails you can type
class Person < ActiveRecord::Base
end
and you will have a lot of auto generated methods representing structure of table people (notice that pluralization is a great feature to improve simplicity and readability as well)
story goes on with
class Person < ActiveRecord::Base
belongs_to :country
end
class Country < ActiveRecord::Base
has_many :people
end
stuff does not even require explanation. it's plain english :)
It's not really different at all...
The author just picked a weak example of Ruby's dynamic strengths. A lot of what makes Rails possible are the advanced constructs and eval contexts available in Ruby at runtime:
Module#module_eval,Module#class_eval, closures,Method, etc. PHP can do some of these things if you're willing to use something like runkit -- which happens to be really buggy and quite a security risk in many cases.Anyway, I didn't want to take this thread further off-topic, but I thought the qualification was worth mentioning.
Modules in Rails? Are you kidding?
Why would anyone want to do Modules in Rails? Drupal is NOT object-oriented, and Modules in Drupal are very difficult to deal with and not straightforward. Very non-intuitive, and there's no inheritance to speak of.
I could see creating an application on top of Rails that would be very Drupal-like, but I would not want to use Drupal as the model for that.
From an ease of development standpoint, Drupal plainly sucks in comparasion to Rails. As far as end-user issues are concerned, for the space of problems Drupal seeks to solve, I might find Joomla a better choice.
So, if you are just looking to lub a bunch of components together to create a simple-minded CMS on a shoe-string budget, then Drupal will probably fill that bill nicely. If you are developing a new application for a website that's more serious than content management, then I think Drupal is a poor choice, and you should do Rails instead.
I am in the middle of converting an application some dufus implemented in Drupal to Rails. This application as it stands now does 100 database queries per web page on average. That just plainly stinks, but is something the Drupal framework encourages. And since this site is expected to handle 10s of thousands of users simultaneously, I am going to have to pull some special tricks to make that work until I can get it fully redone in Rails.
I agree, but...
While I agree with your points wholeheartedly, rebuking Drupal in such a way and in such an old thread is hardly constructive. That said, you should know there are others like you out there, feeling the sharp indigestive pains of an inherited Drupal code base every working day—especially under highly concurrent load. You are not alone.
Actually his fresh rebukal
Actually his fresh rebukal helped me decide whether or not I should continue considering to go to rails bohconf 2011...
Why not just embed an application framework in a module and use that instead of move the entire thing to Rails?
I probably won't go to railsconf, just no time, but the thing is the question is how is an application programmer going to survive their drupal journey? Embed favorite application framework in a module...
Buy facebook fans
sells very real facebook fans and likes that will certainly like your products and are most likely to be turned as your customers. Traffic in this way will be huge, as many of those who are connected with your facebook fans will also visit your site.
Actually his fresh rebukal
I probably won't go to railsconf, just no time, but the thing is the question is how is an application programmer going to survive their drupal journey? Embed favorite application framework in a module...
Wordpress Installation Service
Its a very good thing that
Its a very good thing that Ruby (on rails) for Drupal ..... we are purely accept that both are complementary to each other..