During this discussion on HN, I was surprised to learn that Drupal—the high-level framework I left behind years ago in favor of Rails—has 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 budgets—The 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?

Contrasts

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.

Summary

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.