BostonPHP hosted a PHP Framework Bake-Off last night, a competition among four application frameworks: CakePHP, Symfony, Zend, and CodeIgniter. A developer coding in each framework was given 30 minutes to build a simple job-posting app (wireframes publicized the day before) in front of a live audience.

I asked the organizer if I could enter the competition representing Drupal. He replied that Drupal was a Content Management System, not a framework, so it should compete against Wordpress and Joomla, not the above four. My opinion on the matter was and remains as follows:

1. The differences between frameworks and robust CMSs are not well defined, and Drupal straddles the line between them.
2. The test of whether a toolkit is a framework is whether the following question yields an affirmative answer: “Can I use this toolkit to build a given application?” Here Drupal clearly does, and for apps far more advanced that this one.
3. The exclusion reflects a kind of coder-purist snobbery (“it’s not a framework if you build any of it in a UI”) and lack of knowledge about Drupal’s underlying code framework.
4. In a fair fight, Drupal would either beat Wordpress hands-down building a complex app (because its APIs are far more robust) or fail to show its true colors with a simple blog-style site that better suits WP.

Needless to say, I wasn’t organizing the event, so Drupal was not included.

So I entered Drupal into the competition anyway. While the first developer (using CakePHP) coded for 30 minutes on the big screen, I built the app in my chair from the back of the auditorium, starting with a clean Drupal 6 installation, recording my screen. Below is that recording, with narration added afterwards. (Glance at the app wireframes first to understand the task.)

Worth noting:

• I used Drupal 6 because I know it best; if this were a production app, I would be using the newly released Drupal 7.
• I start, as you can see, with an empty directory on a Linux server and an Apache virtualhost already defined.
• I build a small custom module at the end just to show that code is obviously involved at anything beyond the basic level, but most of the setup is done in the UI.

One irony of the framework-vs-CMS argument is that what makes these frameworks appealing is precisely the automated helpers - be it scaffolding in Symfony, baking in CakePHP, raking in Rails, etc - that all reduce the need for wheel-reinventing manual coding. After the tools do their thing, the frameworks require code, and Drupal requires (at the basic level) visual component building (followed, of course, by code as the app gets more custom/complex). Why is one approach more “framework”-y or app-y than the other? If I build a complex app in Drupal, and my time spent writing custom code outweighs the UI work (as it usually does), does that change the nature of the framework?

Where the CMS nature of Drupal hits a wall in my view is in building apps that aren’t compatible with Drupal’s basic assumptions. It assumes the basic unit - a piece of “content” called a “node” - should have a title, body, author, and date, for example. If that most basic schema doesn’t fit what you’re trying to build, then you probably don’t want to use Drupal. But for many apps, it fits well enough, so Drupal deserves a spot on the list of application frameworks, to be weighed for its pros and cons on each project just like the rest.