Drupal vs. Ruby on Rails

I use both regularly, and honestly I can't say I prefer one or the other. They are just different.

Drupal is a product, that is built around a framework (drupal core). Rails is just a framework. When you install rails you have nothing, absolutely nothing. You need to create a new project, and even when you do that, you still don't have anything. When you install drupal you have a website, complete with users, pages, comments, etc... You have a lot without writing code. With RoR there are plenty of plugins and gems to get you most of the way to where drupal is, but you need to write code to glue it together.

My personal rule of thumb is this:

I use drupal for projects that will be eventually handed over to the user / customer or where the customer needs the ability to change things themselves (add new pages, menu links, etc...)

I use RoR for things where changes will only ever be made by the developer (me).

Personally I like working in ruby / rails. I can do fairly complicated things but the code still seems "clean" to me. For me that's worth a lot. That said I have more drupal projects than Rails projects.

-ray

PHP and Ruby are programming languages. Superficially similar: both are dynamically- and weakly-typed interpreted languages. Below the surface however, they're quite different. PHP's heritage is functional, and more closely related to web application development. Its current incarnation includes object-oriented features, but the Drupal community has been slow to adopt them. Ruby, on the other hand, was designed as a general purpose object-oriented language. (I'm sure I'm inviting a flame war here, but if you care about the beauty and elegance of your language, then it's clear to me that Ruby is far superior).

Rails is a general purpose web application framework for Ruby. It's designed to help programmers be more productive in building web sites of all types, not just CMSs. And note that it's for "programmers". Unless you intend to write server-side code, you can't hope to get much done with just Rails alone (but if you do intend to write code, both Ruby and Rails are known to be very productive).

Drupal is a Content Management System, of which there are hundreds. It happens to be written in PHP, but it's modular design and large collection of available modules and themes make it possible to design and implement a large variety of web sites without writing a line of code. Most importantly, though, at its core (pun intended), it is a CMS. The further your site's needs are from the CMS sweet-spot, the less likely it is that Drupal will be your best choice.

There are CMSs written in Ruby. Refinery, for example. I think you'll find there is a much smaller community contributing to Refinery and other Ruby-based CMSs, and thus fewer off-the-shelf components available (i.e. fewer problems already solved for you).

In the end, you need to start with your site's requirements and who you are. If you don't need a CMS, but some other type of web site, then maybe Rails (or Java+Struts, or Python+Django, or PHP alone, etc) is a better direction. Otherwise, do you think of yourself more as a programmer, or more of a site designer/builder? If you're a coder, compare Ruby to PHP, and the APIs and other tools available for each. Otherwise, compare Drupal to something like Refinery, and the off-the-shelf components available for each.

Good luck!

The thing that I've always loved about Drupal is the way that it puts people directly in touch with their data, and allows them to exert control over it.

When I use Drupal in an architecture planning meeting, it usually doesn't take much time to design and draw out a few content types and associated fields. As long as you don't preface the conversation with, "what I'm about to tell you is going to be a really scary and technical thing," it's actually common sense to get people to start talking about "things" and the "stuff" that belongs to those things.

The next thing that happens is the site owner will start throwing out ideas of her own, like "hey I see what you mean if that author is related to these posts and then the posts are also on the author's page. But what if we relate the posts to this other topic and they show up there too?" That's when I know they're hooked. And because I have a picture in my head of how Drupal already does things, I know which ideas can be implemented rapidly and which ones need a little pushback.

Thus, someone who really knows how to rock Drupal, combined with someone who really knows their own domain, can make a lot of progress very fast. It's also possible, if desired, for that site owner to take total control over her content. She can learn how to add fields without my help, or she can create advanced search pages, feeds, and views without my involvement.

Most of the really great Drupal projects just build upon this mindset. Filefield/Imagefield came from the notion that some of the stuff that belongs to things is pictures. That work became image handling in core, which is infinitely more flexible than cramming a gallery into Drupal would have been. The Date module came from the idea that sometimes your things are associated with dates and times, so you should be able to add those whenever you need to.

I would like it if Drupal were called a "Data Management Engine" rather than a "Content Management System", because that's really what it is. Content is just "stuff on the web", and I think it's more powerful to think about your articles, authors, events, topics, locations, inventory items, etc. as thriving and discrete components in your overall big picture. And it's amazing to give "ordinary people" the power to shape and relate to that information in new and different ways.

Back to the original question, I think that the difference between a programming framework and something like Drupal is where the time investment and skills requirements lie. If your project is about people and their data, and - as Ray says - you're going to make people responsible for that data in the long haul - then Drupal is a good choice.

However, if it's not about people and data, but you really need to micro-manage some specific business process or complicated workflow, you're going to need to rely on programming expertise. In these cases, it's important to consider the tools and languages that will make your programmers the most efficient.

I prefer drupal for database application and ruby for service application.