Yet Another Biased Drupal versus Joomla Shootout

Joomla vs DrupalThis is exactly the sort of thing the Internet needs fewer of, but I'm going to go ahead and pollute the Web with my comparitive experience with the two leading open-source CMSs available.

(I'm not counting Wordpress as a «leading» CMS even though it is more popular than either Drupal or Joomla and clearly falls under the definition of «content management system». In my opinion, Wordpress is too limited to be considered in the same class as Drupal or Joomla. Also because Wordpress beats the pants off of both Drupal and Joomla for use-cases which Wordpress does fit. If Wordpress does what you want done, the Drupal versus Joomla question is academic. If you need more, then it is by definition not a viable option.)

I'm clearly biased here; I'm heavily invested in Drupal. Please take everything I write on this topic with that grain of salt. This blog, my online art gallery, and several other personal projects have all been built with Drupal. I get a not-inconsequential portion of my income from Drupal development and setup.

However, lately I've revisited the question because I have the opportunity to do some Joomla work for paying clients. I'd really like to think of myself as fair-minded and I believe I owe it to myself and my clients to give Joomla a determined and openminded trial.

When I first saw that I wanted to do things with Monochromatic Outlook that required something beyond Wordpress, I went looking at more flexible and powerful CMSs. The first one I tried was Joomla, and for a few days I was totally in love with the new toy I'd discovered. Unfortunately, that joy converted itself to frustration rather quickly. I never got my head around the basic data model (or even determined whether there was a basic data model.) My attempts at building and modifying themes failed horribly, and I found the publishing process confusing. So I reluctantly looked at Drupal, which had been described as more difficult than Joomla.

What I found was a system that I could immediately use. Maybe it's because of my experience programming—this is not the first time that I've been confused by the purportedly easier of two systems (I've never successfully connected a Windows machine to a network but think it's a snap in Linux)—but the learning curve was much steeper than Joomla's. (Note: a steep learning curve is one where more learning happens over a shorter period of time. A shallow learning curve has relatively little rise over more time.) Sure, there was a lot more to learn about Drupal (and I'd be lying to call myself a Drupal expert even now) but I knew pretty quickly how to install and update modules, how to find answers to questions I had, how to create content and even new content types. I was up and running in a short time.

In the past couple of years, Drupal has given me its share of frustrations, which is part of why I recommend Wordpress to anyone that doesn't need more than Wordpress. The only frustrations I ever had with Wordpress were related to getting it to do more than it was designed for. System and module updates are a pain in the ass with Drupal unless you're willing to take your site offline for an hour or else set up proper versioning and rollout procedures outside of Drupal. Drupal people will jump down my throat about that one, but it's my experience.

Now, years later, I'm giving Joomla another try. I've been doing work with a Joomla site for a couple weeks now, interspersed with the other work I've been doing. I haven't had to dig too deeply into it, and that has fortunately given me the opportunity to do some frantic research as I try to get up to speed with Joomla. To my dismay, I'm not up to speed yet.

Here are some specific observations regarding the differences between Drupal and Joomla:

  • Core data type: in Drupal, the basic building block is a node. With few exceptions, everything you make with Drupal is a node, and each has common elements: a title, a body &c. An article or calendar event are both fundamentally the same kind of thing, with different attributes. Joomla's philosophy is to make each kind of information or categorization separate to avoid confusion. Drupal trusts that no one is going to confuse a calendar event and a forum topic even though we can see that they are basically the same kind of information underneath all the extra attributes. For me, understanding a single fundamental idea is far easier than learning multiple types of categorizations which may or may not be arbitrary distinctions.
  • Administration areas: Joomla's administration area is not accessible with the same user as the content areas. Joomla's administration screens are totally separate from the site content. In Drupal, you can specify a separate theme to show for your admin pages to visually distinguish them, but if you log in with an administrative user on the main site, you have access to the admin pages. Admin options are added to the standard site navigation, which makes it easy to jump back and forth between content and administration.

    This is really a matter of preference. I find having to log in twice confusing and annoying. On the other hand, I have to open a separate browser if I want to see my sites as a standard user would see them, without the admin cruft. Though I fall on the «integrated» side of the argument, the other side is a perfectly reasonable position.

  • Functionality Outside of Core: Drupal's functionality is split into modules. Some modules just create a new content type, others add bridges to other software, yet others add dynamic features to a site. Even Drupal's core features (including the parts that can't be disabled) are organized in modules. Joomla has Components, Modules and Plug-ins, each installed and configured differently. Components are separate applications, presumably with some Joomla integration. Drupal would make the integration features a module and let the application stand on its own. Modules seem to be mostly what Drupal modues are: code that adds functionality to the site without adding an independent software package. Plug-Ins are filters that change existing content before that content is presented. An example would be something that turns all the articles on the site into Pirate-speak: «Click here» to «Arrrr… Click here, matey!» That's a bad example, because Joomla also has language support as wholly separate area of customization, but let's set that aside in deference to the illustrative example. In Drupal, Plug-Ins would be modules, or functions handled by modules such as Content Template (contemplate), or Views.

    I sort of understand the distinction between these classes of customization, but I don't understand why the distinction is important to a site administrator. Give me parts that do things and let the module developers worry about the differences in internal logic. Unlike segregating the admin area from the content area, I don't see the upside. If I want to add a feature to my site, do I care whether it's a «component» or a «module» or a «plug-in»? Maybe…

  • Image support: Here I have to give Joomla credit. Image management is a core feature in Joomla. In Drupal there are multiple competing ways of handling images, and those have multiple sets of interfaces for managing and displaying images. Where Joomla generally shows a greater level of balkanization than Drupal (more on this later) there's no confusion about what approach is better to learn for including images on your site. Drupal 7 (which is still not an official release) improves on this some, but the improvement is incremental. Drupal 7 still has no integrated image manager.
  • Data abstraction: In Drupal, a node is a piece of information which can be displayed. A block is a container for information, whether it's one node or many, or even a chunk of static HTML code. Themes provide rules about how to display blocks and nodes. There, you have a conceptual model of the basics of Drupal's organizing principles. You can rearrange, mix and match to your liking. Joomla has «management» pages which correspond not with single concepts, but with parts you see on the site. Go to the «Front Page Manager» to change what shows up on your site's home page. Sections appear to be predefined chunks of real estate on individual pages, and categories are tags for categorizing content, sort of like Drupal's taxonomy except that each category exists only in one section. So really, category could have been called subsection.

    If you're a top-down thinker, interested in manipulating the surface details without having to create a logical set of contexts or organizing principles, Joomla is probably for you. If you think from the bottom up, and can't stand messing with anything unless you have some idea what you're actually doing at some fundamental level, you might be better off avoiding Joomla.

  • Software philosophy: normally, I think that Joomla's approach to Open Source software (Free/Libre Open Source Software, aka FLOSS) is preferable. It's like the difference between the Linux and BSD licenses. The more «free» licenses are actually more restrictive, but that restriction guarantees that more software will be freely available. I understand the pros and cons, and from a purely theoretical perspective, I think that in most cases Joomla's approach, which encourages competition, is the best one. In Joomla's case the result seems disastrous.

    While Drupal encourages the merging of similar projects and modules, Joomla's approach encourages each small developer to create modules on their own, not share information with others, and try to be the best within a category. This is great on a granular level: competition and choice increases the quality of Joomla modules.

    Looking from a wider perspective, however, it's only individual modules that benefit. Without consolidation of important modules, other developers have to either tie their solutions to one approach or reinvent the wheel. Where Drupal has one module (well, two actually—even Drupal isn't totally immune to project schisms) to handle e-commerce it also has hundreds of smaller modules that rely on that one e-commerce package, and modules that provide «glue» between it and other modules. In Drupal, the Übercart Roles module marries the core Drupal user role concept to the Übercart e-commerce package to create a module that permits users to purchase higher levels of access to their website, based on roles set up by the site administrator (note that Übercart roles is so popular that it was rolled into the main Übercart distribution—while it is still its own module, it's available to anyone who has installed Übercart). The author of Übercart Roles was able to (relatively) easily leverage existing code to enable sites to offer subscription content. Though the Übercart module and the code that supports roles is quite extensive, the Übercart Roles module weighs in at about 1300 lines of code—pretty lightweight.

    There are dozens of Joomla modules that do the same thing, but each and every one of them had to build their own e-commerce solution and create their own methods of enabling and restricting access to selected content. A Joomla user wishing to create a subscription website has to sort through all these competing options, many of them costing hundreds of dollars, and none of them having interoperability with the other kinds of products the site might offer. You want to offer t-shirts and website subscriptions? Your customer on a Drupal site can do that easily. I won't say it's impossible to do with Joomla, but the path is nowhere near as clear, nor as sustainable over the long run.

    Remember my complaint about Drupal's image support? That's how Joomla is with its entire catalog of third-party add-on modules.

  • Themes: I'm going to have to give this to Joomla, since everyone says great Joomla themes are plentiful and great Drupal themes are nonexistant. I have to admit, even http://www.whitehouse.gov/ pretty much looks like a Drupal site. The state of Drupal themes is a bit dismal. The only place I'll differ with conventional wisdom here is that, honestly, good themes in Joomla are few and far between too. With either system, you're going to have to pay someone to make your theme look passable.
  • Support: Related to software philosophy (see above) support is a tricky topic. Both Drupal and Joomla have large dedicated communities of users. Joomla has the advantage of a wealth of third-party companies that are charging for thier modules (and components and plug-ins) and which are obliged (if for no reason other than enlightened self-interest) to provide prompt and useful support. The downside is that the quality of this support varies from company to company. But that's no big deal; that's the way the rest of the world is.

    Drupal's support is almost all in the same place: http://drupal.org/. There are other resources, but the forums on Drupal's main website is the clearinghouse for every issue and support queue of every module available. The downside? Some modules are not well-maintained and unpopular, which can make it difficult to get support for them. It's also plagued with quite a bit of FLOSS attitude. Expect your bug reports and support requests to be met with defensiveness and suggestions that you RTFM. Much of the time you'll be pleasantly surprised, but you won't have to wait for long to be told that there is no problem. Sometimes the response will be helpful and other times even a pillar of the Drupal communitry like merlinofchaos can be downright hostile, despite users who have gone the extra mile to devise a solution to their problem.

I'm not going to pretend that this is a fair, unbiased comparison and «declare» a winner. It should be obvious that I remain in the Drupal camp. I find Joomla to be confusing, difficult, and inflexible, and I don't see any redeeming features that suggest an obvious use-case.

At the same time, I don't expect or even desire anyone to change their mind about these content management systems.

Instead, my hope is that by elaborating my reasons I can provide some perspective behind my allegiance. Both systems have failings and strengths, and I hope someone whose mind is unlike mine will be able to see that the things that bother me won't bother her, or the things that I value she does not. I hope that regardless of the choices my readers end up making, that my experience will prepare them for the points of resistance and help them to weigh their options.

In case I didn't make myself clear at the beginning of this post, if you're trying to decide what software to use to set up your blog, and you don't need fancy datatypes or advanced taxonomy or e-commerce, for God's sake don't consider either Drupal or Joomla—just use Wordpress. Wordpress does what it does—makes and manages blogs—almost flawlessly. In fact, even if you think you do need Drupal or Joomla, try setting your site up with Wordpress first. It's pretty easy to move your content from Wordpress to either Drupal or Joomla, and the worst thing that will happen is that you'll come out of the experience with a clearer understanding of what features you need your website to have. You can get a basic shared account on Dreamhost for ninety-seven bucks a year, register a domain (included in that $97), perform a «one-click install» of Wordpress and start your blog going in about fifteen minutes flat. If you have any doubt that you really need Joomla or Drupal, that's exactly what I suggest you do.

You can thank me for the headaches you've avoided later.

Comments

Cheers from the other side of the fence :)
Although I find your post very insightful and even valuable for a current Drupal-based projec I am working on, the very same arguments you use to "discredit" Joomla are in my usual checklist of "anti-Drupal" bashing.

As of version 6.17, i find Drupal to be dreafully chaotic at all levels and, far worse, built upon procedual programming with relatively loose rules, hence the proliferation of hooks to perform even the most trivial tasks.
From Joomla 1.5 onwards, the adoption of the MVC pattern has brought a level of organization, method and discipline Drupal cannot rival with.
Sure it takes longer to develop anything on MVC, but when we are coding really complex extensions, the long term benefits are very rewarding. Any OOP-like application is a lot easier to maintain, extend and upgrade than procedural approaches.

From an admin persoective, nothing horrifies me more than merging the backend and the frontend views. This is particularly true in very large portals comprising heaps of data. Here I think you get things the other way around (admitting that this is a highly subjective matter). Empirical evidence has shown me that most CMS admin wanna-bes are prone to commit the most obnoxious mistakes even when an admin workflow can be clearly told apart from the frontend UI. As in many other areas, here too separation of concerns is a must.

Finally, one can't really understand what Joomla is all about these days without checking brand new CCK's like Flexicontent and jSeblod and enhanced ACL layers the likes of FlexiAccess.
CCK is actually the best and most inspiring module Drupal devs have ever spawned.

Don't forget to take Joomla 1.6 Beta 6 as well. It does not add much to Joomla 1.5 + Flexicontent / Flexiaccess other than bringing multicategorization, taxonomies and enhanced ACL into the core :) Still, a landmark release.

As for Drupal, I only hope I'll be able to survive the commitment I am not bound to :)

Well It has been a huge debate of mine, as I am sure it has many, whether to use Drupal or Joomla as my CMS for my websites. I have been using Joomla for some time and have built few sites under the joomla CMS, although with many frustrations. I have recently been semi-converted over to Drupal by some of the amazing features it includes. (such as multi-site capability, admin ui, integration, and ease of maintaining)

Because of the fact that a Drupal users seem to always swear by Drupal and a Joomla users visa versa, any research I have done on these two CMS have been very biased. Under the rare occasion I may come across a review where someone claims to have used both, generally in my opinion the person had a bad experience gave up and switched without giving both a fair chance.