A little over three years ago I wrote a piece entitled " Assessing Drupal as a Rails developer." In it I attempted to lay out a few of the reasons why I found Ruby on Rails a much more comfortable platform for building web applications than Drupal.
Over the intervening years, Drupal has continued to grow in popularity, and recently we’ve seen the release of Drupal 7. Rails has seen some radical changes with the release of its third major version, but I must confess I’ve no idea what’s happened with its profile and adoption rate.
Over that time I’ve built and deployed many, many Rails applications, and also brought a couple of Drupal sites to the world. Most notably recently there was News Sauce. Drupal’s become the go-to CMS for much of the not-for-profit/charity world and so it’s something we’re constantly monitoring and experimenting with.
The experience of tidying up News Sauce (for the version currently in beta) I was able to get a clearer sense of progress in the Drupal world. One of the major pain points referenced in that older blog entry was the duplication involved in deploying new features, and I’m delighted to see that there’s been huge progress on that front in the form of the features module. Where once you had to go through the cumbersome steps of duplicating a series of interactions, and/or writing a macro, there’s now a relatively easy way to export changes made in the UI to code and to track changes that would affect that code. It’s quite an impressive piece of work, especially when coupled with views and context. It’s great to see that further maturing in the form of the kit specification that begins to give some shape to how the exported features should present themselves (and so how they should interact).
In that context I was pleased to see Jeff Eaton’s recent Drupal 8: The Road Ahead. For Drupal to become a still more compelling platform it’s time for some of the sensibilities that informed the development of features to inform the core system. In general Jeff’s proposals make a lot of sense: some new APIs, a stripped back profile for those who want to build from scratch, and a more developed profile for those who want something that might be described as “a typical drupal site”. It’s all quite good to see.
The changes aren’t enough to make Drupal my first port of call for most of our projects. Ruby—usually with Rails or Sinatra—fits the bill better, and is still my preferred language. But I am far more comfortable with Drupal as a platform than I once was, and I can see it taking a larger role in a number of our upcoming projects.