Darren Mothersele

Software Developer

Warning: You are viewing old, legacy content. Kept for posterity. Information is out of date. Code samples probably don't work. My opinions have probably changed. Browse at your own risk.

CMSs are dead, long live CMSs

Aug 2, 2013


A few people have asked me what happened to my site: is it still Drupal? Where did the comments go? The short answer is I’ve joined cool crowd and started experimenting with static site generators, but I’m going to give you the long answer. It’s a multi-faceted issue, and an excuse to finally blog about the end of the CMS era. And, no, I’m not leaving Drupal. I still very much believe that Drupal is the best tool for a lot of projects. I just don’t want to manage my own site that way.

I’ve always believed in finding the right tool for the job and over the past six months I’ve become more convinced that a CMS is not the correct tool for simple projects (like my little website). I don’t need fancy editing tools or online administration. In fact, I’m more than happy to edit my site in my text editor of choice (Sublime Text). I spend most of my working life inside Sublime Text, so it makes sense for me to edit my blog here.

Death of the CMS?

I think we’re in a post-CMS world now. I don’t think there’s any need for the WCMS (Web Content Management Systems) we’ve become accustom to. I’m talking about the kind of web page editing CMS, like Wordpress, Joomla, and probably most installs of Drupal. We should be thinking about Future friendly content, structured content, mobile first, COPE (Create Once Publish Everywhere). Content needs to be structured and needs to be flexible, and that means we’re not just editing web pages anymore. Instead we need to think about Microdata, RDF, RSS, Web Services, mobile first, Apps, etc, and of course whatever the future may bring. It’s impossible to future-proof yourself entirely, but with a strategic approach to content, and well defined content model you can at least be prepared for whatever may come along in the future. Essentially, modelling and capturing your content without thinking about how it is displayed.

The second driver for this is marketing automation and full digital platform integration. The enterprise world is full of horrible buzzwords around WEM (Web Experience Management) and it’s clearly something that Dries is gearing up the Drupal project for. Did you notice this in his keynote at Drupalcon Portland? Dries no longer mentions Wordpress or Joomla as competitors to Drupal, instead he’d rather talk about Adobe’s CQ5, Sitecore, and Oracle’s WEM.

Long live the CMS

So the CMS has to adapt. Drupal is already well placed to do this because of it’s flexibility and existing ecosystem of integrations, and Drupal 8 brings us even closer putting web services at the core of Drupal.

The end result of this though is that CMS become much more complicated beasts than they already are if they want to remain relevant and useful. This puts them out of reach for a lot of people, and there’s a lot of simple projects that don’t need all these features. That’s where the static site generators join the party.

I think in this post-CMS world, systems either join the big leagues and get enterprise features, or they simplify and become tools for quickly building sites.

For my blog I’ve gone with the latter. A simple tool that just generates static web pages from a template.


The decision to change my site was motivated by several things:


I took the text of some articles from my site and gzipped them (because my web server does that too before sending). An average article came out at 7kB when zipped. When viewed as part of my old Drupal-based site it came out at 14.4kB, and when you include downloading the CSS, JS, etc it would be 158.6kB. Wow, 158k for a 7k article!

But I’m not the worst offender. I tried some random other sites. For example CNET, a 1.2kB article resulted in a 18.1kB HTML source, and 1.3MB total download for a single page. On the BBC News website a 758 byte article (tiny!) came out at 71kB HTML source, and 501.5kB for the whole page.

I’m pleased to say this new site, for the same 7kB article, comes out at about 50kB with all the CSS, images and JS. that’s less than a third, and most of that is the PNG of my smiley face! :)


I played around with Jekyll initially but I found Middleman to be much more flexible. Plus, Middleman is what we’re using for prototyping responsive designs and quickly building mockups.

Basically, you give your files two extensions, what you want it to be, and what it is, then Middleman watches the files and translates them as needed. For example, if you’ve got a style.css.scss file then Middleman converts it from SASS into CSS. I’m writing my blog posts in files like 2013-08-02-new-blog.html.md and it’s converting them from markdown to HTML.

You’ve also got loads of cool preprocessing stuff like partials, and you can use Ruby templates, Rack plugins for your asset pipeline, and deploy your website with just one command: middleman deploy

There’s a load of contributed modules that add on extra functionality. It comes with a blogging module that adds some nice features for managing a blog.


I wrote a very simple Drush command that output the content from my blog to a set of flat files. I could just render the nodes and save them as HTML because Middleman can use that as a post format. I’ve switched to using Markdown for future posts, but it doesn’t matter that the old posts are in HTML.


I can edit my blog posts in the text editor (Sublime Text) where I spend most of my life. I can easily preview edits (with Live Reload, nice!), and then build and deploy updates in just one command. The server does very little work to serve the pages, and it’s very cacheable. I could even now move my site to being served by GitHub Pages or similar.

A static site generator is a good idea for simple web projects. CMSs are adapting, and Drupal is preparing to take on big enterprise projects.