Choosing a CMS (and how the web works)

In the past few weeks I have had a number of direct conversations or made indirect observations about a number of websites run either by individuals or by organizations that are still using some form of static HTML generator when they probably should be using some form of content management system (hereafter CMS), almost all of which produce HTML dynamically.

What’s the difference between *static* and *dynamic* you ask? Static HTML pages sit on a server, typically in a folder/directory titled `public_html`.

Now let me make this clear for all my friends who have asked me, or were about to ask me, that static HTML generation is great for the internet.

### Comparing Code

A pretty fundamental, and arguably not very interesting to most users, way to compare the various CMSes is to look at their code base. [Dries Buytaert](http://buytaert.net/cms-code-base-comparison) has done so. His graphs reveal the size of the code bases over time.

It turns out that the Drupallers are themselves prone to reflecting on what they do in relationship to WordPress. There have been a number of threads over the years. [This one in particular](http://drupal.org/node/29364) reflects on ease of use issues. And here’s [another discussion](http://groups.drupal.org/node/15689).

Web developers regularly ask this (http://ask.metafilter.com/131535/Drupal-vs-Joomla-vs-Wordpress-vs) precisely because they want to be able to deliver to their clients a stable, robust platform that is very user friendly. If any of those three dimensions fail, they know that the client will fault them, not the platform. But what do we mean by stable, robust, and friendly?

> WordPress is really slick for quick, turnkey web sites that don’t really need much functionality beyond a blog and an ‘about’ page.

> Drupal definitely has a learning curve, but it’s your platform if you anticipate needing to integrate a lot of custom functionality; its biggest strengths are its APIs.

Leave a Reply