Drupal vs Rails
During this discussion on HN, I was surprised to learn that Drupalthe high-level framework I left behind years ago in favor of Railshas a high-octane elite consulting industry behind it with the same prestige and perhaps even more clout than the Rails community.
This gave me pause, because for me Drupal was always the option for demanding clients with razor thin budgetsThe type who waxes on casually about a laundry list of features that sounds like Yahoo’s homepage and then comes with a four-figure budget as if that should amply fund a Facebook clone.
But companies like Acquia are an obvious indicator of just how shallow and murky my end of the pond was when I first formed my opinion on Drupal. What are the true advantages of Drupal vs Rails for elite web consultants?
Drupal has much more common functionality and it’s better integrated. Rails’ functionality is more modular and lower-level.
Drupal theming and layout is easier, getting you to a working site in minutes and styling in general is much less work. Rails is more flexible, being CSS framework agnostic and allowing minimalism or complexity to taste.
Drupal has a heavy data model and rather unique API which allows modules to follow common patterns and work together more naturally. Rails starts with no data model, so you build from scratch but you can tailor to your exact use case without any unused overhead.
Primary Use Cases
Drupal excels in cases where you have huge amounts of content and a wide variety of essentially boilerplate functionality to integrate all over the place. Large content sites like bbc.co.uk or whitehouse.gov would be the poster children for this type of site.
Rails excels where you have a very specific and unique data model and you need to tailor every aspect of the site and UX around that data model. Almost any startup fits the bill here, since it is generally implicit that the backend powering the service is unique. It’s hard to imagine building Github in Drupal, for example.
In essence Drupal hands you a mountain of functionality that is surprisingly flexible for its sheer volume, but for which the cost of adding new functionality is relatively high. Rails gives you only primitives (maybe with some higher level engine gems that still require a fair amount of glue code to integrate fully), but the cost of building functionality is relatively minimal.
In order for Drupal to make economic sense you need to be able to use a significant portion of that mountain of functionality. In fact you need to use enough of that mountain to cover the additional cost of custom development when there is no applicable module, or UX assumptions diverge from Drupal core’s.
I would summarize the distinction as Portals vs Startups. The archetypical Portal is exactly the kind of site for which Drupal is optimal and Rails would be a money-sink. Likewise, the archetypical Startup would not want to get mired down with Drupal’s prescribed data model when they are trying to iterate rapidly on a concept.
Of course, the vast majority of sites out there are neither as massive as a Portal, or as unique as a Startup. Suddenly the water is murky again, but I think this is still a useful lens with which to make early website technology choices leaving personal biases aside.
Jonathan Rochkind says…
October 4, 2012 at 7:30AM
Well said, i think you’ve expressed it just right.
When you’re in that grey area, it often comes down to developer’s personal predilections (do you want to spend the time to make the app just right, is that what you find fun? Rails), as well as amount of resources the project has (does it NEED to be something that will keep working for quite a while with little to no continued developer attention? Drupal with no custom functionality. Anyone that’s had to maintain/upgrade a rails app over rails versions will prob agree).
October 8, 2012 at 2:31AM
Nice comparison, i agree with you. Now that rails has full-features engines probably will be easier to share high level functionalities also in rails.