I’m fascinated by the trajectory of web publishing. As a web content editor and (several years ago) a freelance web developer, I’ve used each of the following content management systems and web publishing “tools” over the past 15 years:

  • Drupal
  • Wordpress
  • Joomla
  • Alfresco
  • Dreamweaver
  • static HTML (via text editor)

I’ve rarely had the opportunity to choose the content management system or publishing platform where I’ve worked, but rather inherited existing projects or been forced to defer to an IT team.

The reality is that few projects I’ve worked on merited the complexity of a full-fledged CMS (when they have, Drupal has usually been the appropriate solution on account of the functionality required).

In years past, I’ve used Wordpress to publish my personal blogs, but for this blog, I ditched the database and went with a static site generator: Jekyll.

Moving away from CMS

Content management systems are used for primarily two reasons:

  • to ease publishing for non-technical web editors
  • for database-reliant functionality, such as user roles, workflow, and managing comments

A few years ago, I read a compelling blog post by Dave Cole of Development Seed.

The tl;dr of the Dave Cole article is summed up pretty well with this quote:

By developing websites as “client-side” applications that only consist of the files directly usable by a web browser with no extra work done by backend servers, we are able to pass on substantial cost savings to our clients while virtually eliminating risk of the website going “down”.

The article goes on to describe how external APIs can now offer functionality that used to make sites database-dependent. For example, Disqus can be used to manage comments on an otherwise static-site-generated blog.

For non-technical editors, Development Seed has created an authoring environment called Prose. For slightly more technical editors, many static site generators manage site content via markdown files.

Jekyll

Jekyll is a static site generator created by GitHub co-founder Tom Preston-Werner. Because of its lineage, it has mature integration with GitHub and GitHub Pages. Sometimes called “the blogging platform for hackers,” Jekyll uses the Liquid templating language and individual markdown files to compile a static site. Jekyll is mature enough now that there is thorough documentation, tutorials, and templates to get started.

Liquid

Liquid and other templating languages bring many of the content management features of a CMS into generating static sites. For example, you have control flow using for loops, which my template uses to generate the list of blog posts.

Command line

While Jekyll does require some skill with the command line, you really only need to know a limited set of commands to manage a simple blog or site. Most the time, you only need to know how to navigate to your blog directory using:

$ cd location_of_blog
$ jekyll serve

Other static site generators

Its affiliation with GitHub, along with the immense popularity of the latter, is why Jekyll is extremely popular for static sites. But there are many other static site generators; Hugo and Middleman are others I have considered using.

Jekyll + iA Writer

For this blog, I pulled one of many Jekyll themes to get me started, editing the style sheet and some templating elements to suit my needs.

As I mentioned in a previous post, I use iA Writer to author my blog posts (as markdown files).

Here’s the general workflow:

  1. Open up Terminal and cd to my blog directory
  2. Use jekyll serve to initiate Jekyll (this will also generate a local server which allows you to review changes in your browser as you make them)
  3. Open up iA Writer and begin a post with appropriate front matter
  4. Save post as a markdown file into the _posts directory
  5. Convey contents of _site directory to your web server (or let GitHub Pages build your site and host it for free).

That’s it! You don’t have to deal with databases, plugins, or most of the security issues that plague database-driven content management systems. You don’t need to know PHP or configure modules or manage a load of dependencies. And you can add functionality via APIs such as Mapbox or Disqus. Best of all, you can focus on writing without worrying about all the technical bloat and maintenance of a CMS.

Admittedly, I use Jekyll in very limited ways, but I like the simplicity of it (some might say it’s more complex than using a CMS, but they probably don’t know what’s going behind the scenes of their CMS!).

We’ve come full circle, from the static sites of the early web, to heavy, intensive, and vulnerable database-reliant content management systems, and now back to static sites in the form of static site generators. At least for sites where it makes sense, which are many.

Headaches, but not migraines

As with any publishing platform, there are annoyances.

I am not a barbarian, and consequently I insist on using smart quotes on my blog. I was able to achieve smart quotes in my blog copy, but the content rendered from the YAML front matter was saturated with dumb quotes. It was driving me crazy for weeks, as I tried to find a solution. Finally, I discovered that iA Writer has an option to use smart substitutions for quotes, which means it automatically replaces dumb quotes with smart quotes.

This is great, but YAML mixes scripting with content. Syntactically, values in YAML are surrounded by quotes, but they must be dumb quotes in order to work programmatically. Consequently, smart quote substitutions in iA Writer actually break the functional application of the front matter, so I use a fancy work-around (the sophisticated technique known as ‘copy and paste’) to prevent my YAML quotes from becoming smart quotes. To further complicate matters, I want the content in the dumb quotes to contain smart quotes, as that content generates the titles and subtitles for my posts.

It’s a bit of a headache, but it’s not the migraine induced from maintaining a database-driven CMS.

Publishing platforms

As a web editor, I’m obsessed with publishing platforms and workflows, and I’m always on the lookout for new publishing tools. I follow the design and development of Medium and Chorus (to the extent the entities responsible for each share information), and I am part of the massive Drupal community via work.

But it feels like there is still room for a publishing stack that focuses on writing and maximizes editorial control and effectiveness. For now, a static site generator and an elegant writing app are about all I need.