Drupal: Difference between revisions
Osejisycym (talk | contribs) No edit summary |
(No difference)
|
Revision as of 23:44, 23 November 2010
Critisisms of Drupal
I would call Drupal the software I love to hate, but it's more simply the software I hate. In my peer group I seem to be in the minority for loving the rigour of Java based systems, which I think is completely appropriate for any system that is meant to be constantly built on and redesigned over long periods of time. Systems based on fine grained standard components are easy to build on, robust, and provide all the customization you could wish for.
Unfortunately Drupal has caught on with my typical client, the smaller non profits who can't depend on an IT department. So I'll try to constructively criticize it here. I would love for this list to become completely outdated as Drupal tackles these problems. All of them have been mentioned as "to dos" by the Drupal "executive" for several major versions, with no progress.
No data model or high level API - api.drupal.org is documentation, not an api. When the top-down API changes, code just breaks, often without warning. Manipulating "entities" using array references and text symbols is a one way ticket to hair-pulling debugging, bad quality data, and porting pain. It inherently creates queries that are incredibly complex the kind thing models and APIs were designed to solve, but can't be used with Drupal. So code is built that the developers themselves barely understand, is inefficient and difficult to build on.
As an example, a project I'm working on with a university was originally, after some angst, targeted for Drupal 6.x. After some months of work, it was decided to switch back to Drupal 5.x, even though t's not the current version, because some key modules don't yet work with Drupal 6.x. But guess what, by the time the project is done, Drupal 7.x is likely to be out. So, because of the drawbacks of PHP and Drupal, nothing is compatible, resulting in a littered field of abandon ware, outdated documentation, things that half work. This isn't how Java projects work.
Of course, Drupallers think working with this kind of code is high-tech, but it's really macabre.
No relational support. With CCK (which is a reinvention of what a real CMS is, though it has the most interesting potential), this is amplified. Data integrity is out the door, and you have to reverse engineer your own designs.
And most of all the disingenuousness, the intellectual dishonesty of the lead developers. They are happy to sit back while Drupal is covered with acclaim, when most of them are pretty hardcore and know about the real problems and lack of design, the fact that Drupal basically builds on arbitrary hooks, switches, massive use of arbitrary text for logic, and entity design that are all gigantic steps back from what solid programming tools provide. There isn't a piece of documentation that isn't filled with superlatives, yet in reality decades old wheels are being reinvented with more attention to hype than care. And for some reason many Drupal mid level developers act as uncritical apologists, though if you search at all you can find endless posts inquiring about incompatible versions and the many hacks required to get normal things done.
http://www.inertweb.com/2008/12/21/how-i-learned-love-drupal - a fair article that's "for" Drupal. Though he still completely glosses over all the advantages of using decades of well designed software in favour of something that always does things its own way.