Back in the earlier days of blogging, things were different. Most of the popular content management systems that blogs ran on were static page generators, like Movable Type, the package that previously held WordPress’s throne, before a price increase caused a mass exodus in 2004. Movable Type stores your content in a database, like WordPress, and it has an administration panel where you manage your content and adjust settings. But that’s where the similarities end. Instead of assembling pages dynamically, the blog engine compiles them into static HTML pages ahead of time, so the web server can just throw them back to users instantly. It’s a lot easier on the server that way, which can result in a snappier web site and less chance of your site going down from a social media bump.

This is, of course, something of a simplification. Many WordPress users, especially those with larger sites, use caching plugins like W3 Total Cache to have the best of both. The dynamic model is used, but frequently-accessed pages are statically cached for performance.

Something I’ve noticed recently is that some bloggers are making a return to the old days, using modern static page systems that are even simpler. Jekyll, Hyde, Pelican and Toto are lightweight blogging applications written in Ruby and Python. They don’t use databases at all, instead preferring flat files checked in to a Git repository. You write your posts in your preferred plain-text editor, name the file appropriately and check it in to the repository, then run the script from the command line. It iterates through the files, merging them with your theme, and outputs static HTML files.

It’s not terribly accessible to people who don’t know their way around a command line interface—and version control software, for that matter—but it certainly reduces the hardware required to serve the site up. You don’t need a database daemon running, you don’t need PHP. Just your HTTP server, whether you prefer NGINX or Apache, sending static files along when somebody asks for them. You can even run the script on your local computer, and push the compiled pages to any web server.

Another issue is that these new lightweight blog engines don’t have commenting built in. You will have to use something like Disqus or IntenseDebate, unless you build your own alternative that can be included with JavaScript.

All in all, I find the idea very intriguing. I don’t think I want to give up the ease of use (or plugin support) that WordPress offers for this blog, though. I did consider switching to Jekyll or Hyde when I revamped my personal blog recently, but didn’t commit to it.

Further Reading

• Getting Started With Toto, a Tiny WordPress Killer
• How To: WordPress to Jekyll
• Building Static Sites with Jekyll
• Hyde Documentation
• Pelican Documentation
• Octropress — a “blogging framework” for Jekyll

However, WordPress isn’t necessarily the ideal tool for every job. Sometimes you need to define multiple types of content that don’t follow the post/page hierarchy too well. For example: You run a large website that has articles (posts), but it also needs to have a link directory. It would be the most elegant solution to have a category full of empty posts with custom fields to hold the link titles and URLs.

A situation like that is where people normally would push you towards a “real” CMS like Drupal or Joomla, with their ability to define different types of content (e.g. articles, podcasts, forum posts, a link directory). But why do that when you could just use the Pods plugin.

Pods is a CMS framework that lets you create, manage, and display your own content types. Don’t bother hacking blog posts into becoming something they’re not. With Pods, create entirely new data structures with only the fields you need. Like Drupal CCK, you can set up relationships, allowing for a whole new level of interconnectedness.

Pods is a nifty little tool that unlocks a lot of possibilities. I’m currently trying to set up a new event calendar with it on one site, instead of manually editing a static page on the blog. I defined a new “Pod” called “event_calendar,” set it up to have a top-level “Events” menu in the WordPress admin, and defined a few data fields. Now I can easily add new events, which are stored in their own database table, separate from the main wp_posts table. All I have to do now is finish setting-up the page that will display the list of upcoming events.