I never liked WordPress much but it's a "good enough" solution when one needs a blog. Plus it's easy to get up and running quickly. Well, enough is enough! This blog now is statically generated and uses an external service to store, process and handle comments.
After working on it for way longer than I anticipated (mostly because of comments, see below), I finally got it working exactly the way I wanted. Here's how writing blog posts looks like now:
And afterwards a single grunt deploy publishes my post to the server over rsync. How's that for a workflow?
Advantages and Disadvantages of going static
Why would you want a static blog anyway? Here are some pros:
- Full control over your contents. No more chasing for rouge output that your blog engine decided to stick in there without your knowledge.
- By extension of above: Making your own template from scratch is a bliss. No more hunting for
wp_deregister_script( 'jquery' );bullshit. - Speed. The content is already rendered, no need to access content from the database. No need for Wordpress (or other blog engine) to do it's thing with it.
- Security. One login screen less.
- Use your favourite code editor to write your blog posts and get instant preview. How cool is that!
- By extension of above: work on your posts offline (e.g. on a plane).
- Use Source Control to maintain drafts & backup your contents.
- Process your contents: What you write is now a source and what you publish might be a heavily altered version of that. You can keep your input clean and still have desired output, see section below for few examples.
Admittedly there are some drawbacks:
- Handling user input (e.g. comments) is not exactly trivial (but see my solution)
- There are things that you get 'for free' with Wordpress (and most other blogging platforms) that you need to take care of now, such as the theme, the rss channel and social meta tags to name a few.
- Admittedly this solution is only for developers. Also if you're using your iPad to write your blog, you're most likely out of luck.
Static Blog Generator
There are many off the shelf solutions available, and some, like Jekyll, are well-polished and quite popular. However I wanted one that I could customize and while learning Ruby in order to be able to do this does sounds tempting, I didn't have time for it. Furthermore I wanted one that would integrate nicely with my build workflow which resolves around Grunt. And that's exactly what assemble can do for you.
If you're familiar with Grunt, setting up a simple grunt-assemble workflow is a matter of minutes. You can use the one I've put together when I needed a quick dev-blog setup for my Archers! game. Of course it takes little longer when you want to add customised processing as I did for this blog. Here are few examples of what you can do:
- Use Live Reload feature as on the above video
- Process blog contents, e.g.:
- Automatically attach ids to headers and generate anchor links (e.g. official plugin, my version)
- Use node-based version of highlight.js to parse code and print colourful syntax.
- Write helpers to automate some contents generation, e.g.:
- Get a next/previous post (by date) or a related post (by tags, category etc.) and link to it automatically at the end of every post (see my nextArticle helper)
- Use nchart to pre-generate chart and embed it in the post (like this)
- Check for dead links as part of a deployment process.
Of course since you're using Grunt you can make this a part of your usual workflow, have your less/sass processed into css, your js built & uglified etc. Furthermore you can (and probably should) automate publishing/deployment whether it's rsyncing it to the server, publishing it to Github Pages or sending it over ftp.
Comments
As mentioned before comments are problematic when your blog is static - there simple is no backend to receive, process and store comments for your blog. One solution is to use a third party service such as Discourse or Disqus. However I don't like these for few reasons:
- I want to keep the discussion on the blog, not move it to a third-party service
- These solutions are relying heavily on JavaScript, potentially making your blog appear unresponsive and/or load/render longer
- Some people won't see these - be it because of third party cookies, privacy concerns or ad blocking. I personally block all third party cookies and all embedded social networks contents.
My approach is simple: REST API with processing facility: let everyone post comments (encrypted) to a public endpoint (use CORS to limit cross-site abuse), strip sensitive data (e.g. comment), process them through Akismet, then optionally ask owner for approval before making comments accessible on a public endpoint. The implementation I've is an early MVP and even though it still needs more work, I'm using on this blog right now. If you're interested in more details, it's open source. I hope to further develop, document and release the comments API solution in next few months. Give me a shout if you have any suggestions!