vaporstun

The other downside of Features in Drupal is that if we export something as a Feature (say a View) and then our site builders tweak and change that View for our clients and then we update some core element of that View and re-export the Feature, that re-export will overwrite any custom changes that were made to that View, thereby trashing any of the custom changes. This is a real problem with Features to which I'm surprised there has not yet been a good solution.

> Your comments comparing Rails and Drupal surprises me. I feel like you are writing without realizing how Rails development is done.

First, no offense taken.

Next, I do have a fair amount of experience developing in Rails (it's my go-to hobby framework and I MUCH prefer developing in it to Drupal as I thought I imparted in my original comment) and yes, there are gems that get you most of the way there with some of the tasks I described, but our site builders (read: non-developers) are unfamiliar with the command line, could not generally install gems without intervention from developers and, if necessary, could not extend them without developer intervention. That is what I'm trying to describe.

With Drupal, people who interact only with a web browser can install rich components from a library of modules developed by others with integration with the Content Types (basically the equivalent of Rails Models in Drupal) with zero development.

Looking back at my original comment, arguably my time estimates for development were exaggerated to some extent and could be shortened with the use of gems, but the fact remains there is, at current, no way for users, through only a web browser, to enable that kind of rich functionality in Rails. That was the point I was trying to get across.

You don't have to write much code but you still have to write code. This makes it a non-starter for a particular class of user.

Drupal developer with 4+ years of working with it under my belt.

The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites.

The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites.

I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does.

This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients.

(1) The client wants a Google map of all their events

(2) The client wants the Events displayed on a calendar

(3) The client wants Events to filter by Event type

(4) The client wants a tag cloud or something else totally unrelated to the Events system

Built in Rails (Total additional developer time to add these features: 400+ hours)

(1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything.

(2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.)

(3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless.

(4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development.

Built in Drupal (Total additional developer time to add these features: 0 hours)

(1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons

(2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar.

(3) No developer time because the site builder went into the Views settings and added an Exposed Filter

(4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed.

Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community.

I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works.

tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!