Top 5 Reasons Developers Don't Use Drupal
Wed, 2008-04-09 16:35 — Nick Lewis
Jeff Whatcott ponders why Drupal isn't dominating the job postings for social app PHP developers. He guesses the main problem is lack of awareness and understanding of drupal among the greater developer community. With this line of thinking, the obvious fix would be outreach and education. Personally, I'm skeptical that the developers who choose systems other than drupal do so because of lack knowledge, or awareness. I think its something far less rational
I. Our API is Only as Powerful as the Developer's Knowledge of It -- When I developer first starts poking around the hood of drupal, they'll probably be totally unaware of how hook_menu works, what the formapi is, how our template engine overrides, etc... If they took the time to read up on all the documentation, they'd probably become a drupal convert. Unfortunately, developers are lazy, and prone to thinking anything they don't totally understand is "crap".
II. Developers Hold a Deeply Held Believe that *their* tool is the best -- Converting a Rails developer into a drupal developer is about as easy as converting a Muslim to Judaism. Ever tried to convince a Rails developer that drupal's modularity gave it a huge advantage for building complex applications that would have to grow over time? Yeah, I stopped 3 years ago too...
Oh, btw, RoR sux. lrn2theme. Drupal FTW!
III. Developers Often Don't Form Opinions From Experience -- Most developers like to sound smart. So when in doubt, they naturally look to the opinion of someone else who they think is smart. Making matters worse, developers have a tendency to think people they agree with are the smartest.
IV. Anti-PHP snobbery. The snob factor is huge. PHP's reputation among the elite opinion leaders in the development community is about as good as most people's opinion of communism. Making matters more difficult, PHP5 took care of most of their gripes, but nevertheless, they continue to quack the same anti-php song, and that hurts drupal.
V. Drupal Doesn't Speed Up Development for Developers Who Aren't Drupal Ninjas -- Learning drupal takes a lot of time. If time is short, and developers aren't familiar with the APIs, even I'd recommend against Drupal.
Syndicate
Recent comments
- I think there needs to be a
1 week 5 days ago - Hitchens did rather well........
1 week 5 days ago - Cult?
1 week 6 days ago - Hey
1 week 6 days ago - I could not agree more with that particular point
2 weeks 23 hours ago - Great note taking.
2 weeks 1 day ago - Too many places to configure small things
2 weeks 1 day ago - Nah no fading out or
2 weeks 1 day ago - Apologies, it was great
2 weeks 1 day ago - Good points
2 weeks 2 days ago
Comments
Reasons not to use Drupal
I've been working with Drupal for about three months now and like others here I find it very frustrating.
I don't have a lot of experience in using MySQL and PHP, but I've found that using these tools rather than working with modules is a much better way to get things done. In some cases I can write PHP code and a MySQL query in less time than it takes to click through Views and work around its bugs.
Drupal's Web interface is cumbersome. As others have pointed out, it requires too many clicks and too many page loads to perform even simple tasks.
The Drupal forums can be helpful, but in the past few days I've noticed that they're off-line more often than not. I don't think that's a coincidence.
There's much to be done
I agree with the points in this article, however I have some issues with Drupal of my own.
I'm very fond of Drupal, but don't love it. The platform has some issues of its own. I read in one comment about the delight of working with the API documentation - I am sad to report myself on the other side of the spectrum. For the most part I've found module development to be a frustrating guessing game trying to figure out how the bits and pieces are supposed to work together because in general the documentation lacks order, proper examples and thorough explanations. I found very knowledgeable people on the forums, but we need to get more knowledge on the documentation itself.
Drupal needs some marketing campaigns to promote use and documentation contributions.
I love drupal
I have been a PHP developer for quite some time, but I just discovered drupal and it's beautiful API. The API documentation is just wonderful and it is a dream to work with, and it didn't take that much time to learn thanks to a great tutorial on building modules.
The module system is another fantastic feature. It's hard to find code that expresses the object oriented architecture so clearly without actually using the built-in language features for doing so.
The downside is the administration, which can be a little bit hard to work with.
I am deeply impressed by the drupal project and I will probably use the platform for all my future php web projects.
Ugly and painful
I have 4 Drupal sites and I'm getting less happy with it all the time. Every new version upgrade is painful and traumatic. The developers make no attempt to preserve backward compatibility, so most of the contributed modules I depend on are broken by every upgrade. I still haven't been able to upgrade any of my sites to 6.x because views, CCK, buddy list, and user points, among other modules, have problems with Drupal 6.
Aye
I have to confess I agree somewhat. I am still trying to learn/catch up with the D5 release, and now we have D6. That's great, but what really aggravates me is that despite the lack of any forward motion with D6 (no Views/Panels/CCK for D6 practically cripples it) there is NO noise from the community surrounding the fact that we have already set a code freeze date for D7!
This to me seems complete insanity. Yes, I've heard the arguments, but frankly, developers cannot be expected to stop working for great swathes of time, relearn all the APIs, rebuild all their modules due to dependencies etc, once a year. It puts a massive strain on project support, both financial and time-wise. Personally, I think this is Drupal's weakest point, and it's one that continues to frustrate a great many people. If anything will become Drupal's "undoing", it could be this. I know people will disagree, but there has to be a healthy level of respect for legacy, otherwise the smaller dev agencies just won't be able to support the system.
There has been noise from
There has been noise from the community surrounding the code freeze, I would argue that you just haven't been listening in the right rooms :). A lot of the "noise" is actually hard work being put into getting a comprehensive testing solution for core.
Views and CCK, among others, are killer contrib modules that many, many sites rely on. Because both groups of maintainers decided to do a rewrite it means the 1.x releases of both modules aren't a simple port to Drupal 6.x.
I'm quite fond of the mantra "the drop is always moving" and because of Drupal's development cycle I would argue that it breeds an environment of innovation and independence.
Agreed. Keep core moving
Agreed. Keep core moving above all else. Every release opens up significant opportunities for new modules that would be unthinkable in past versions.
I agree mostly -- though we
I agree mostly -- though we must not discount the value of cleaning up the messes of the past. I think its a bit melodramatic to say that the fast pace of core development will be drupal's undoing. The problems getting CCK, Views, and Panels up to drupal 6 is largely the result of those modules having to work around API problems in drupal 5. Drupal 6 provides a clean way to do what those modules need to do, the challenge is simply removing all the workarounds in the code.
And don't worry, Drupal is unlikely to release 7 until the community is on board with 6. And yes, 6's improved API is work the pain of upgrading modules
It has gotten a bit nutty
Honestly, I think it's the simultaneous combination of both things together (e.g., no backwards compatibility AND an extremely rapid core development cycle) that makes the situation so frustrating for people who are *actually* trying to get work done with Drupal. From the standpoint of those people it's like, 'fine break my compatibility when something new comes out, but give me 2 years of good productivity from what I have now before making it obsolete', OR - if that doesn't work for you - give me new release all the time, but make sure I can upgrade easily'.
Unfortunately, at the moment the current method of Drupal core development effectively ends up being along the lines of, 'Hey, let's release something then call it old even before it launches and have something even newer out AS SOON AS FRICKIN' POSSIBLE - and who cares if the rest of the contributed modules to run a site are done or not!' (and in fact this IS what happens - I've been in irc when core developers started beating the drum to get Dries to up a new core branch well before the new core release was even out - how's that for planned obsolescence! Also, witness the lack of help Earl has gotten)
To make matters worse for newcomers, and by extension for the Drupal project's long-term reputation - there are no warnings that the above situation exists - it's something people get to find out after investing themselves in Drupal.
Fortunately, there is still plenty of good to be had with smart use of Drupal and upgrade planning, but I wouldn't want to try and navigate the planning of a large/complex site without the years of experience I've have to know what's a good move and what's not.
The situation sucks, agreed.
The situation sucks, agreed. The best solution, imho, is to name certain contribs as being required for an official drupal release. I know I know, I already can sense Boris Mann bringing up, "who decides, who's responsibility, etc.", but clearly, there are certain contribs namely views, cck, devel, coder that's importance is self evident. Personally, I think what really needs to happen is CCK and Views in core, but that's a whole nuther topic that I don't want to bring up.
Too many clicks !
I only started using Drupal couple of months back and surprisingly, finding APIs was one of the easier things to do thanks to api.drupal.org (I love how you can see the full function right there and look at all the cross references). What I found tons more frustrating is that in the admin part of the site, everything is so many clicks away. If I want to remove 5 fields from a content type, I need to click a total of 10 times with as many page loads. This doesn't sound so bad at first but when one has to do similar things everywhere, it becomes very painfull. Admin menu comes in so handy because of this very reason because it saves you 2-3 clicks everytime.
I think reducing the average number of clicks required to perform admin actions should be a priority. I think last SoC, somebody did a module called Fast Toggle which tried to address this issue in some of the places. We need a blanket overhaul of the same kind.
DHTML Menu
Use something like DynMenu or DHTML Menu to make the admin menu more navigable. You'll still click the same number of times, but you don't have to wait for a page load each time.
It's gotten to the point where I can't stand to administrate a Drupal site without that module (DHTML Menu) - it's the first thing I install when I set up a site.
The entire admin section is
The entire admin section is a bad idea IMHO -- most of those settings would be much better of living directly inline with the pages they effect. CCK settings, taxonomys, should be about 3 steps closer to a node add form IMHO.
What Nick said!
Sometimes I feel like all I do is hack administrative shortcuts into the theme layer to save my clients (and myself) the headache of trying to figure out where something is administered. The number of clicks and page loads involved in administering blocks can be downright embarrassing.
From an administrative standpoint, the benefits Edit-in-place functionality could bring to CCK text fields alone cannot be overstated. Yet, every time some badass takes up the cross they seem to run into all kinds of obstacles in core.
In-place editing
This needs to be available in Drupal. I'm drooling here. :P
Well, thats NOT all
I might contribute a different point of view.
I come from the Zope/Plone (Python) world.
Why i use more drupal today?
Because the pluggable-components approach of drupal is helps doing agile incremental work.
But do i love it? To be honest: no.
The pragmatic book-keeper in me forces me to use the tools that are efficient.
The price pays the geek in me with a sense of esthetics.
patching around in drupal and its modules often sucks.
Did not see much beautiful code in my drupal life.
To be honest, my heart is still in the Plone community for its culture of code esthetics.
Maybe in some years i will be back to plone, for the new zope3 is based on pluggable components too.
Maybe with time and php5 the sense for nice code rises in drupalland.
Maybe both?
I would love to see some drupal-patterns-wiki or such.
me too
"I would love to see some drupal-patterns-wiki or such."
me too.
alex_b
Hmmm,
I think you illustrated your point perfectly. I can't ever imagine you finding something better than Drupal.
I confess to sharing all the
I confess to sharing all the typical characteristics of developers that I listed above.
Oh, btw, RoR sux. lrn2theme.
Hahaha! Well played sir, well played.
Perhaps we need to not only
Perhaps we need to not only publish the api, but also write a ton of tutorials and examples. Also make sure that these are in one location that makes sense.
Even an occasional example
Even an occasional example in the API docs would be nice. Actually, if you look closely, there are some examples, but it is really hard to tell that they are examples, since you just expect API code in that location,
Examples
Examples are exactly what we need more of. At least that's what I've been told by more than a few other people. That would go a long way toward lowering the barrier to entry into drupal development.
Agreed
An acquaintance, who happens to be Plone developer, literally thinks I'm crazy for using a PHP-based CMS. No amount of proof/features would convince him to change.
PHP snobbery
It is very easy to write a PHP script. Equally easy to write an insecure one or just simple crap. Also, I believe that the PHP team could the handle security bugs a bit better. PHP thinly erapping a lot of libraries, each with their own naming conventions does not handle consistency. Releasing PHP 5.0 as broken as it was -- while I absolutely understand the problem with people not testing -- did not really help matters.
We know that PHP is a great language. We try to spread the love. Drupal people spearheaded gophp5 which eventually will help. And so on.
Well -- that's one of the
Well -- that's one of the weaker arguments against PHP, any person with a bit of logic can deduce that creating something of low quality with a tool does not mean the tool itself is low quality. Anyone who reads thedailyWTF knows that there is just as much awful code written in C#, Java, and Python as their is in PHP. I'd argue that PHP 4 encouraged low quality code with lack of language features, but PHP5 (now that it is stable) has made that a mute point.
how true
Nick,
How true this is..
Thanks for sharing.
Shrop
Post new comment