First of all, apologies for the misleading ‘cagematch-y’ tone of the headline. Everyone is a winner in this blog post, including you, dear reader. If you’re following these words you obviously care about the underlying infrastructure of a website which, in my book, makes you smart and beautiful.
As a project manager overseeing Drupal projects, I find myself often comparing the Drupal framework with my previous training as a developer in Ruby on Rails. What’s clear is how accessible and doable it is to learn how to build a website on both platforms. With a framework like Rails, there’s a level of abstraction involved in building an application (the framework does a lot of the work behind the scenes for you) that allows for a speedy learning curve.
With Drupal, the level of abstraction is even greater, where deploying a basic Drupal website doesn’t require you to write one line of code.
As convenient as this is, a Drupal application is designed to handle an enormous amount of complexity, specifically, the kinds of complexity that comes with managing and organizing ongoing content creation and handling workflow among a team of editors — a point that leads me to my first distinction between Rails and Drupal.
Convention vs Configuration
What I love about Ruby on Rails is that it was designed to refine the developer’s process, addressing some of the major pain points that come with sharing a code base within a team or inheriting a complex website from another developer (a person who is typically a nameless, faceless entity by the time the project lands in your lap).
As you can see from the below rSpec file that I created for a Hunger Games app, Ruby is a highly semantic, expressive language. A well-written Ruby file can typically be understood at a glance (and enjoyed almost as much as a YA novel? I'll let you decide.):
Much like in the world of smart phone devices, where Apple offers a highly designed interface, assuming the role of determining an elegant user experience for the user, Rails is also a framework that’s thoughtfully designed for the person using it (the engineer). The Ruby on Rails motto is “convention over configuration.” Every line of code has its place, every feature is encapsulated in a self-contained piece of logic that can be removed or extended without touching other areas of the application. The structure and organization within RoR apps are designed to be as consistent as the cells of a honeycomb. A Rails team in Omaha and a Rails team in Guam are likely staring at very similar file trees.
There’s a right way and a wrong way to do things as a Rails developer with little encouragement for experimentation when it comes to process. While it may sound restricting, the benefit is that there’s very little time spent hunting around for a piece of code responsible for a given feature, or the fear of being thrown into a web of mysterious bugs when one feature is changed or enhanced. Routes (commonly known as URLs) are dynamically created using a RESTful API and defined in one file. The system leaves more time for the actual work of building and supports an agile development process.
Drupal on the other hand, while not necessarily being the opposite in terms of extensibility and level of organization under the hood, is built with a very different focus — it’s designed with a team of publishers in mind. The glory of Drupal’s organizational structure is in the dashboard. Creating content, organizing content with taxonomy terms, deleting, reverting to previous versions of published drafts, these tasks are assumed by Drupal and are available with a basic, bare bones website.
It’s not only intuitive to use for the end user, but the dashboard offers a much welcomed point and click interface for a developer like me who’s used to doing everything at the command line. Adding a new gem in Rails (something equivalent to adding a module in Drupal) requires adding code via a text editor and running an install command in the terminal. In Drupal, a similar task can be performed in the command line (using Drush), then simply checking a box to ‘enable’ the module. Voila.
Objects vs Content Types
The power of Drupal is the ability to build a custom layout piece by piece, like Lego pieces, that are tied to specific types of content. Much like in Rails where the Object is the center of the application, Drupal’s Content Type is the blueprint for many instances of similar content to be created, read, updated and deleted. A typical Object in Rails would be a User. A User object would be given Attributes such as username, email address, job title and company bio. A typical Content Type in Drupal would be a News Article and can be given a title, subtitle, a body of text (editable with a WYSIWYG editor), commenting capability, byline and publishing date.
It’s All About Workflow
While my appreciation for Ruby on Rails hasn’t lessened since working with Drupal, comparing the two frameworks has helped me see the strengths of using Drupal for content-driven projects. It’s a framework that’s built to handle complex business rules (highly configurable) and supports the content development life cycle.
Here are some impressive Drupal features that can make an editor’s workday incredibly efficient:
1. “Who’s Online” feature (ships with Drupal core)
See when other team members are logged in. A handy tool to ensure your team members aren’t unwittingly re-writing each other’s work in real time. In my days as a managing editor, this happened more times than I care to remember.
2. Robust CMS
Sort your content by state (published, unpublished), type (newsletter, article, page), author, etc. and recently updated content is flagged for you and floats to the top of the queue.
3. Do-it-all dashboard
image via drupal.org
I’ve seen the dashboard extended to manage various tasks that relate to publishing such as sharing style guides, tracking newsletter statistics, tracking event invites and attendance. Yes, Google products can handle many of these tasks, but why not keep it all in one dashboard?
4. Version control
image via drupal.org
A CMS like Wordpress will allow you to track versions of a post, an indispensable tool to see your content’s history. Drupal takes it a step further by allowing you to view, revert or delete versions of an entire layout. Why would you want this? Let’s say you’ve asked your development team to upgrade the layout of a certain page. They do a bang up job and it’s developed so quickly that you didn’t even have time to gather the content for that page.
In Drupal, it’s possible to have both versions of this page existing at the same time, one in a ‘published to the public’ state and another in a ‘published to admin’ state. This allows you time to build the content that’s necessary for that page and merely ‘flip the switch’ on the newest version to make it public when you’re ready to present it. This allows your development team to also work more efficiently. They can deploy the new feature and move on to other tasks, saving them the effort of navigating bottlenecks that come with upgrading parts of a website and timing their efforts with cross-team deliverables. Everyone can work a bit more autonomously and launches have the potential to be handled much more smoothly.
In conclusion, much like in WWF wrestling in the 80s, you can’t really compare the merits of Macho Man Randy Savage against those of Koko B. Ware. Why would you even do that? There is no winner and no loser. There are only different approaches to the same game (full disclosure: I do love Koko B. Ware just a tad more, but I don’t know why).
Rails is a fantastic way to build simply as a way to manage complexity. With Drupal, it’s clear that to achieve simplicity, it sometimes requires a complex framework.
