Drupal's Golden Handcuffs

  > If you find yourself writing large amounts of custom 
  > code in Rails, then either you are truly tackling a 
  > novel problem that no one has ever dealt with before,
  > or you are simply unaware of the gem that you should
  > be using.

The language that has the libraries I need is always the one I end up using.

1. When it breaks, it shatters—as you said 2. WordPress's UI is so much better for clients, in my experience 3. Theming in Drupal was a nightmare — div.class > div.class > div.class

It's such a shame about Drupal. It's so capable, flexible and powerful, but the ui is a tough sell. You can build almost anything with it, but when it comes time to theme and eventually time to hand it off to the client, that's where things got hairy for me.

At my work we've got a team of "web designers" building websites using Drupal. It allows them to build most of the stuff that clients want for their website/intranet, without writing code. For the more business-logic heavy applications that need to scale and continuously require new features there's a separate team of Django developers.

This approach seems to work fairly well: designers get to build pretty advanced stuff they normally wouldn't be able to without some programming help, developers don't get the boring CRUD/shopping cart stuff.

Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows. Assuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't), it's true that each developer could export their own version of the given content types, views, etc., and commit them to version control. The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result? All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy.

Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere (see also Drupal's "database abstraction layer" or its supposed "object-oriented design").

1. The client wants a google map of all their content 2. The client wants the content displayed elsewhere too 3. The client wants to filter the content by type 4. The client wants a tag cloud 5. The client gets what they want quickly by using drupal and is happy. ... 99. The client wants to change the google maps module to act slightly differently, but this turns out to be very difficult, and their developer takes days to make very simple changes. 100. The client is complaining that their website is slow because it loads over 200 drupal modules, but they need them all. 101. Some code is the db, and some on disk, which makes it very difficult to trace execution. 102. The client can no longer update their drupal as half of their modules are no longer maintained, and they're at the mercy of the module developers to do so, this causes problems using new modules which expect a newer drupal. 103. New developers can't get up to speed because the code-base is so convoluted and the database contains over 200 tables with a byzantine structure caused by drupal's over-abstraction of content types - the client runs through a series of several drupal developers and bleeds money with no significant changes to their site and lots of bugs left unfixed. ... 200. The client gives up and starts again with a site rewrite using another framework, and curses the day they were introduced to drupal.

The up-front development cost may sometimes be lower with drupal (though for many sites I would dispute that, most frameworks make it a matter of minutes or at most hours work to add a tag cloud for example, or add a map, with the advantage that you don't have to use a module to do it), but unless you are very careful and stick with one developer, the huge technical debt you're taking on by using it doesn't justify that. The fact that the developers ever thought it was a good idea to store code and views in the db is a huge red flag, and is a huge temptation to some developers and/or clients to produce a huge complicated, unmaintainable mess. Even if you try to control this it doesn't ledn itself easily to separation of concerns.

I'm sure it's quite possible to produce clean websites with drupal and keep them under control long term, but it's not the pattern of the sites I've seen, and I don't think it really gives you so much more in the longer term over developing in simpler frameworks which don't try to prescribe as closely how the content is structured.