There is a lot of talk at Drupalcon about how they stack up against the competition. We are in the weeding-out phase of the Web Content Management System market, when most of the myriad contenders will fall by the wayside. Those who make a living building and using Drupal naturally want their platform to be among the survivors.
Drupal, according to their own assessment, powers about 1% of the Work Wide Web. The Drupalistas estimate that WordPress accounts for just north of 8%. There is another system called Joomla that is roughly even with Drupal. These three look to be the survivors in the Great-Web-site-in-a-box sweepstakes.
Honestly, I was a little surprised that Drupal considered WordPress to be a competitor. Sure, they both want to be used for more and more of the Web, but does Lego consider Tonka to be a competitor? Here’s the deal: Drupal says WordPress is the most popular Content Management System (CMS). I say WordPress is not a CMS at all.
That’s not to say WordPress isn’t a fine tool, in fact, this blog uses WordPress. But would I use WordPress for my current paying gig? No. Honestly I dread the day when WordPress becomes a big, fancy CMS like Drupal. That’s not what it’s for. There is a reason WordPress is the big dog, and it’s not because you can build sophisticated Web applications with it, it’s because you can install WordPress, find a nice skin, and get your stuff on the Web in an attractive and intuitive way. WordPress is a publishing platform, and a pretty good one at that.
Drupal, on the other hand, begins to shine at the next level up in terms of sophistication. It is the Lego to WordPress’ Tonka. There is considerably more design up front, and much critical functionality must be added as external modules that don’t come with the main (“core”) code. (Some of these things will be added to core in Drupal 7.) Maintenance of a Drupal site is more labor-intensive as well, as updating the parts is more complicated than with WordPress.
In exchange for the added complexity, you get a lot more flexibility. That’s not to say that WordPress can’t be used to make sophisticated Web sites, but generally speaking WordPress is optimized in putting a defined sort of information (like blog posts) on the screen in a very flexible way. There are hundreds of ways to add other pre-defined data types (for instance, there are shopping cart plugins), and all that works really well and most people are going to be happy with that.
Drupal is the tool you use when the data types in WordPress won’t do it for you. In Drupal you are building a Web application, where with WordPress you are using a Web application. Step one in building a site with Drupal is designing the data and the relationships between the various data types. Drupal allows you to design your data without having to design your database. Some of the ways Drupal implements your data design are pretty hokey, but it works. You can create pretty sophisticated data models without knowing a thing about how a database works – or even what kind of database you’re using. (In fact, you’re better off not knowing how the data is structured, because things can move unexpectedly as you tweak your design.) You are also presented with an almost dizzying set of options to decide who is allowed to see, edit, or create each little piece of each data type you define.
Once you get your content types defined, then you can move on to how to get actual content into the system (handled pretty much automatically), and how to present specific subsets of your data on the screen. To get at the data one often uses views, which are built using a tool that generates (frustratingly limited) database queries and then processes the results with a gratifying set of options tailored to each data type.
Then it comes time to put stuff on the screen. To control where things go and when, there are regions, blocks, panels, panes, pages, and so forth in a nonintuitive overlapping of roles. Blocks and regions and pages are built in, but the profusion of other options is a testament to the limited way they work together. For all the flexibility of Drupal, GUI building is still clumsy, though getting better (I’m told).
At last we come to the task of making the output pretty. For this purpose Drupal uses a maze of performance-sucking php template files that are invoked using a system of names that allows one to set up the display of information at just about any level of granularity. Many of these templates go hand-in-hand with specially-named preprocessor functions that allow you to customize how data is prepared for presentation.
Drupal separated the preparation of data and the presentation of data to allow people with different skill sets to do the different tasks. The template files can be done with only a minimal amount of php, while the preprocessors are where the real logic is implemented, unencumbered by HTML and CSS. This also has the effect of putting the risky code out of reach of those who aren’t expert in Web security. All good things.
I used the phrase “performance-sucking” above, and I meant it. The designers of Drupal made a conscious decision to emphasize good architecture and flexibility over fast execution. This was the same decision Google faced a few years back, as they developed ever-more-sophisticated pattern matching algorithms. While competitors kept things simple to reduce server load, the folks at Google decided that the cost of processing cycles and storage was tending toward free, and chose to emphasize the quality of the information they provided instead. Similarly, Drupal has decided to make things in a structurally sound way and spend the processor cycles and disk reads necessary to support that.
Drupal 7 will be even slower, but will be more scalable (they say). What that means is that although the software is not as fast as it could be, its behavior is predictable as demand increases, and it is easer to scale up your site as things go huge. Good structure pays greater and greater dividends as things get bigger.
All that stuff Drupal has makes it a more complicated to get up and running, and for a simple site (or even one of moderate complexity but with a relatively straightforward data model), WordPress is going to get you to the promised land with a lot less pain.
I am led to believe that the WordPress community feels it needs to compete with Drupal just as much as Drupal thinks they need to compete with WordPress. Toward this end WordPress 3.0 will have new features that answer some of Drupal’s flexibility advantages. All I can say is “PLEASE, WordPress, don’t try to be everything Drupal is.” That WordPress is not everything Drupal is constitutes its greatest advantage. Stay with your market, WordPress!
I hope you get visitors and commenters from your end of the expert spectrum. I will provide a comment from the non-expert side of the spectrum.
As is my unpleasant habit, I will begin with a long-winded intro. I was watching a TED episode the other day (I don’t know enuf about TED to explain it, but it is popping up more and more around the web and youtube, and seems to be some endless series of seminars by experts….hey! you should be a drupal seminaring guest). So this TED seminar was by an architect who attempted to build her house as green as possible, and do the cool thing of measuring the energy involved throughout the process. She did a great job, but then said that the building industry and media spent enormous amounts of time analyzing the greeness of the paints and ointments, while the big player was the wood materials, and the elephant in the room (there’s THAT phrase) was the number of flights she made a year…like to a TED seminar.
Which is a longwinded way to say, I am going to use an “elephant in the room” point.
You are teaching me how to program nice websites. It has come time for T to have her own business website. I did not even attempt to go thru the process of finding a hosting service, and domain name register, etcetera etcetara. While Drupal and WordPress are fighting over single digit percentages of the web we went to the elephant in the room:
Yahoo.
As non-experts, as laypersons, as technophobes, we just one-stop shopped and used Yahoo’s black box TV to dial up a nice website with several pages, ready-to-go forms, easy-to-insert maps, and ready-to-wear graphics.
Maybe Drupal wants to be the thing behind the curtain – the thing the Yahoo engineers use to make their one-stop-shopping-website-builder-4-technophobes. But that means your analogy with Tonka and Lego is less apt. It might be better to say WordPress is Tonka while Drupal is the metal stamper that pressed out the dumptruck form for the Tonka toy.
To switch gears…regarding performance. Over the years, when looking over forums an’ sich about computing I’ve often seen comments about performance. But I’ve always been struck by how subjective these statements are. I am not aware of (tho that doesn’t mean it doens’t exist) of actual metrics and benchmarks of web performance. I think it would be cool for someone to build a desktop widget that would stand to the side of your current web programming project and it would have a set of virtual dials that would measure the performance of your project. Tachometer (well, speedometer) for projects. Getting back to the TED seminar, what is needed is METRICS! It wasn’t until the architect measured the process that she discovered the embedded energy of house paint is trivial compared to other parts of housing construction, yet the whole industry was expending lots of angst on this trivial part.
Let me clarify that my not building my own website is NOT a statement on your tutorial abilities.
You bring up a good point, Jesse. I know that Yahoo has a WordPress option, but I don’t think it is the default. My sweetie uses Yahoo, but an older system that is no longer supported, and there is no migration to the current system.
Which sucks, and makes me worry that Yahoo could do that again to the new batch of customers.
There are a lot of ‘slap up a few nice pages’ options for building Web sites, but although it’s debatable whether WordPress is a CMS, those are certainly not. Also I suspect that of those quick-Web systems, Yahoo’s share of the overall Web is less than 8%. (Although how you measure that share – total domains? traffic? – will affect the number dramatically.)
Still, that’s an awesome business model – No hassles, no worries, just go to one place and have your Web site ready to go. I have a friend who has discovered that the market for people who want a Web site but haven’t the slightest clue where to start are willing to pay a little extra annually just to make the hassle disappear. He’s finding that a large enough group of merchants would be willing to pay a couple hundred bucks and $15 a year to hand someone their print flyer and say “put this on the Web.” You do enough of those, you have yourself a business.
This would be taking the no-hassle Yahoo account and removing yet another piece of uncertainty. All the client does is hand someone money and some sort of document with what they want on the Web.
Were I to go into that business myself, I’d use WordPress, because it’s the tool I’m most familiar with, but any of the lower-end quickie packages will do. My hosting service comes with two or three of them in a neat package, along with a mechanism for me to resell domain names.
I could do a thousand of those, then let my annual domain service markup provide a nice secondary income with no effort on my part. There are people in this business, and many of them turn around and use Yahoo and like services, though I don’t know if that gets them recurring annual revenue or whether Yahoo keeps all that.
A thousand?! I think I’ll leave that for the other guys.
On the subject of performance, Google provides excellent analysis of site performance (they load pages from every site on a regular basis after all, and if your site loads faster it saves them money). The analysis includes suggestions of ways to improve performance, like by combining CSS files into a single file.
I believe they do have a widget for that.
As far as Drupal goes, there are places in the docs where it says, “you could use a function but we recommend you use a template file even though it’s five times slower.” Even that is hard to measure, because if the template file in question is already cached then the load time is greatly reduced. In the end site builders have to run a stopwatch while loading the page – which is what Google does, along with counting how many different pieces of different types they have to fetch.
This site gets pretty low marks for performance. I had some caching turned on that helped a lot, but things started to break. I think now that the caching wasn’t the culprit, so when I have time to fiddle with it I’ll be turning caching back on and see what happens.
Work wide web is the corporate side of the internet?