The Post-CMS Landscape

In The No-db Landscape I wrote about the differences between “flat-file” CMSs and static site generators. Today we’ll have a look at the idea of a “Post-CMS” and some new developments.

I didn’t make up it up, but I love the idea of a “Post CMS” world and it should resonate with anyone who has devoted countless hours to installing, configuring, updating and coding big content management systems. To my mind, “post-CMS” means the disaggregation and, in many cases, elimination of the component parts of a CMS. What remains is simply the tools we need to for a particular project and nothing more.

Is there such a thing as a Post-CMS CMS? Perhaps, but it doesn’t look much like what we’ve known in the past. A post-CMS CMS may or may not have a database of some sort, and it may have an editor and many other facets of a CMS, but it won’t have layers of pre-built software that comes with it. Each of those components is not only entirely optional, but may very well come from different sources. They’re ála carte rather than prix fixe; tapas rather than Beef Wellington!

An exemplar of this approach is the static site generator Just launched in March and already proving to be popular, Metalsmith, built on Node.js, is as sophisticated as it is simple, owing to its “everything is a plugin” philosophy.

Statically generated sites are but a subset of the post-CMS paradigm and actually the most minimal manifestation; the opposite, in most cases, of a CMS. When we think of static site generators we think of content in markdown or text documents, or perhaps a JSON file or even a spreadsheet, which is then processed through templates with the result being an entire website generated at once. There are trade-offs to this approach and one of them is the lack, at the moment, of a truly competent web-based editor.

Another recent trend: Entirely separating the function of content management from the functions of displaying that content on a website. Stripping the “system” from content management, these tools are billed as “content management as a service” and are entirely focused on the content editing aspects of a website. In fact, none of the features of a content management system are present other than actual content management. You can use your content on as many sites as you like; it’s all available via an API to deploy with, typically, a variety of programming languages.

CMaaS examples include Osmek, Contentful, and Prismic. Webhook is a closely related example, though it’s a fully blown system, it is also a static site generator.

One contender in the CMaaS field,, has created their own static site generator, baked.js (blog post). Additionally, the community has contributed plugins for Metalsmith to integrate both and Contentful.

One aspect of static site generators I enjoy is the ease with which one can move content from one application to another. After all, these are developer tools and should be chosen to fit the job. One wonders though, with the CMaaS systems, how easy it would be to move content from on system to another if a provider went out of business, changed their service or pricing, or your needs changed.

Search Options for Static Websites

Here are some options for adding search and/or filters to your static website. These have various approaches, costs and ease of implementation.

The less-technically inclined may want to look at something like Swiftype (paid, but has a limited free option), Tapir or Tipue. I use List.js extensively for filtering and recommend it highly.

How Vox Media uses Static Site Generators

I’m constantly on the lookout for sophisticated and interesting uses of static site generators. Here’s the forward thinking Vox Media on their use of Middleman as part of their publishing strategy:

In a nutshell, our Editorial Apps system consists of a static Middleman site, which is populated from one or more Google Spreadsheets at build time (using our middleman-google-drive extension, which we’ll talk about in a future article), and then deployed to Chorus by doing a git push and using git post-receive hooks, in a way not unlike deploying an app to Heroku.

Read the rest at Vox Media’s Product blog.

This is interesting for a lot of reasons. Vox is, aside even from their publishing efforts, is on the forefront of content management with their Chorus CMS, so I’m happy to hear that static sites fit into their vision. I’m also interested to hear that their using Google Spreadsheets for data. As easy as I find Markdown documents and YAML lists, not everyone feels comfortable with them and a spreadsheet is comfortable and certainly good for some data, and, of course, using Google Spreadsheets has the benefit of being great for collaboration.

I’ve seen others use this approach. Jim Pravetz used GS for an online shop and wrote about it on his blog (“Generating Jekyll Pages From Data”), though I believe he’s now using Shopify for that site now. Coderwall has a brief tutorial on “Use a Google Spreadsheet as your JSON backend” too.

Vox has made the source code for the Verge-50 site public so anyeone can benefit from their work.

Getting Started with Static Site Generators

Here are some of the blog posts that first got me excited about the potential for static site generators:

Jekyll Content Decision Tree

With the addition of collections in Jekyll 2.0 there are a lot of choices one can make about how to structure their site. Besides collections, now you can also add JSON files to the _data directory. I put together this decision tree to help anyone who needs it. This, of course, reflects my own way of thinking about content in a static site generator context, specifically applied to Jekyll. One thing I love about not using a database is that your content is much closer to its original form: documents are documents, data is data. Note that this variety may very well change in the future as collections pages and posts converge toward one content type, likely to be collections with optional features of posts, I’m guessing.

Download the PDF