Monday, August 17, 2009

Drupal: Too Primitive For Practical Use

It sometimes irks the developers among us that dumber and half-baked solutions gain so much momentum, in comparison to what they would consider the more elegant systems with well-engineered software architectures. Such is the case, for instance, when considering WordPress (the dumb one) or Joomla (the half-baked one) in comparison with Drupal (the engineered).

I'm admittedly not a hard-core Drupal developer, but I've done my share of PHP and loads of software development with database applications. I decided to spend the day setting up a Web site on Drupal. It was very illustrative of why Drupal is liked by institutional users, and so often tossed to the side by everyone else.

In comparison with Joomla, the core architecture of Drupal is indeed very elegant. It is sort of the Common Lisp of content management systems. And that is its biggest shortcoming. The problem with Common Lisp, contrary to appearances, is (not(the(nesting(of(parentheticals))))), but the expanse of details that a person must keep in active, working memory in order to construct a picture of what in the world is going on.

The processing of XML became not only commonplace but easy under node-oriented API's, and particularly with XPath, so the node architecture is not to blame for the overload. Rather, the Drupal community fails to recognize the benefit of encapsulation and task-oriented procedures.

Users have identifiable goals that have nothing to do with extracting modules or making node lists. Why is there no package management system? Drupal developers can obviously write coherent instructional procedures (see creating a gallery and creating another gallery), but the user interfaces hold them down. It is an extreme disadvantage to write user instructions when the necessary steps are at such a low level compared with those typically required for Drupal's half-baked cousin Joomla. In Joomla, when it works, installation and configuration is often as simple as a one-click upload and editing some settings.

Now, I decided to post this when I wanted to set up an image gallery -- actually a portfolio. I know how it should work, and I can even see how Drupal's nodes could be set up to configure the items, then queried to build the list, etc. But check out the links above if you haven't already. My only response from this morass is to laugh out loud. Are you serious people?

It makes sense to have features installed as separate modules. As a developer I think it is quite elegant actually. Yet as a user trying to get a deliverable out, it is just so much unnecessary clutter. What I want to see is packaged units I can install and use immediately. Ideally I would like to see the undercarriage of Drupal, but with packages to address specific user needs, much as Joomla components give coherent package management and configuration.

No comments: