As I’ve indicated here a few times, when announcing site launches and offering a few hints and tips, I fairly frequently find myself working with Drupal but have long had reservations about doing so. What I’ve so far avoided doing is going into much detail about why that would be, what those reservations are, and so on. But now I’m working on a review of a Drupal book and so it seems appropriate to lay those cards on the table and look at the details on them. It seems easiest to do that by comparing with the framework I do most of my development in: Ruby on Rails.
As ever with technology comparisons, just like any other sort of comparison, a lot of my preference for rails boils down to a combination of taste and experience. I’m also well aware that I’m comparing unlike things. Rails and Drupal set out to solve different problems, and so obviously take quite different approaches. That doesn’t mean, however, that developers aren’t often left choosing between them as the boundaries are blurred and there is significant overlap between their respective domains.
I’ve seen plenty of bad ruby code, but proportionately I’ve seen a lot more bad PHP, and as a PHP-based solution Drupal inherits some of that baggage. Drupal has pretty good support for a wide range of cutting-edge ideas and tools, but by and large the Rails community has seemed much more clued-in to what’s happening at the forefront of web development. That may of course change as the Rails community continues to transition from being chiefly early adopters to a much more mainstream crowd, but it marked my early impressions of the framework.
A case in point is the integration of automated testing in Rails. There is some community support for automated testing in Drupal (primarily through the simpletest module) and there are plenty of Rails projects that lack tests, but there is a strong focus on Test-Driven and Behaviour-Driven development in the Rails community, and the combination of Rails’ object orientation, simple rake tasks and fixtures/mocks makes it very simple to write a solid test kit.
Testing is complicated by the hooks system in Drupal. Hooks are a powerful feature, allowing any module to broadcast and listen for a variety of events and respond appropriately, but it can be difficult to know what order modules will receive those events and so you end up performing a variety of contortions to make sure your responses are given the appropriate weight. Arguably Rails’ layers of filters and plugins can introduce similar complications and I’ve certainly spent quite a bit of time tracking down performance hits coming from rogue filters in plugins and engines, but so long as inheritance is properly handled it’s not all that difficult to do a little introspection to make sure everything’s in its right place.
The fact that Drupal relies heavily on web-based configuration makes it easy to put a lot of power in the hands of admin users, reducing the reliance on a developer, but it also makes upgrades and deployments a more complex business. When I add a new module to an existing Drupal project I usually find myself noting down the steps I take to configure it in my development and/or staging environments so that I can repeat that process in production. In a Rails project I’d write a migration and set up capistrano to run that migration when I push my new version live, significantly reducing duplication. The Drupal approach may be simpler for non-developers, but as a developer I frequently get frustrated at the repetition of tasks that could be so much easier.
That issue is one of the key things pushing me away from the nice-in-concept CCK. Adding new content types to a site through a web interface is an appealing idea, but it’s a pain to have to work out how that changed things in my database to produce a script, or to have to repeat a manual process. Since I know how, I’m much more likely to produce a module for my new content type, simply because I know that deploying that is a much quicker process.
One reason it’s been fascinating reading the Drupal book I’m currently reviewing is that books on Drupal are so thin on the ground. That’s a real shame as while there’s a lot of content on Drupal online, it’s not really been well organised for experienced developers wanting to build serious solutions who aren’t already intimately involved with Drupal. By contrast, while the Rails books are mixed in quality the best ones not only get you up and running fairly quickly, but provide a good entrance to exploring the internals and writing effective extensions. That’s not necessarily a reflection on the core projects themselves, but both online documentation (where, admittedly, Rails is still lacking) and books make a significant difference to the developer eco-system and quality of the solutions that are likely to be built.
I don’t mean to sound too negative, and I’d love to receive comments showing me how to address the shortcomings I perceive. I’ve built sites I’m proud of on top of Drupal, and where their focus is a good fit for Drupal’s core features or mainstream modules it’s been a very good solution, providing a suite of content management tools at very little cost. But as soon as there’s serious custom development to do, those advantages tend to dissipate pretty quickly when set alongside the advantages of Rails for agile, regularly upgraded and well tested solutions.
Tags: comparison, content management system, development tools, drupal, PHP, religious war, ruby, ruby on rails
James thank you for the article. I’m also in your position and often facing the same question.
I think it all comes to the functionality of the website. Managing content with Drupal is very easy. With few clicks you can enable a forum, a blog, user roles / groups etc. Coding these components from scratch with Rails is a lot of work (though fun) and a huge time investment.
My problem with Drupal is customization. It often becomes painful to modify a module or core functionality to make the system work exactly how I want. This is why I started to build my own Rails libraries for my CMS needs.
I should also add that finding a reliable and affordable Rails host has also been a problem for me. With Drupal all needs to be done is (at any hosting company) copying the folder and importing the database.
I’ve found that building user roles, and blogging tools takes less and less time with rails, thanks to an ever increasing understanding of the problem domain and the chance to re-use code. It’s still more work than enabling them in drupal, but I don’t think I’d describe it as a “lot of work”.
But I’d definitely agree on the customization side. A huge amount is possible using drupal’s hooks in custom modules, but it gets fairly hairy and can quickly offset the advantages of using an off-the-shelf system.