Building a static website

I’ve been quite busy over the last couple of weeks revamping my blog. I had originally started with a dynamic site built upon Drupal: I wanted to learn how modern content management systems (CMS) separate content, style and functionality. I took a bit of a learning curve around topics like CSS, responsive website layout, some PHP, database management and whatnot. A lot of the problems I had to deal with stemmed from the sheer complexity of Drupal and its plethora of the available modules of varying quality, at least when the result had to be perfect in terms of code highlighting, typographic finesses, color schemes, web editor, anti-spam measures. There are also rather great components like the Omega theme on which I finally settled to base my design upon. In the end, I was pretty content with the look-and-feel and with what I’ve learned.

Why a dynamic website is oversized for a simple blog

But all I’m after is to write a blog post every now and then, and to experiment a little here and there with CSS and Javascript to improve the design and user experience. For this use case, a dynamic website is like using a sledgehammer to crack a nut. The maintenance was a nightmare. Even with the assistance of the awesome drush and quite a bit of background from my daytime job about how to properly build, deploy and version software, it was too much effort to get a proper deployment pipeline with a local test site, a remote staging site and a production site up and running, so I basically found myself crossing my fingers that my productive website wouldn’t go boink because of some obscure database update or unresolved dependency nightmare. I had to fight off spam attacks. And the site was slow: PHP code and database lookups are server-side operations, which means they are a potential bottleneck — in particular if you share the resources with other users — and don’t scale well when your site becomes crowded suddenly.

Enter static websites

The “static” part refers to the absence of server-side logic, meaning that the content just consists of flat files which come to life by means of the client-side technology stack HTML (content), CSS and webfonts (style), and Javascript (client-side program logic). Flat files mean that

  • you can edit them in your editor of choice as opposed to some crappy and buggy web interface,
  • organize them in a version control system,
  • build, preview and deploy your site using your favorite standard tool chain,
  • no-one can hack your site because it is just a bunch of dead files on a read-only share.

Static content providers are available on very high quality, performance and availability standards. If you leverage the power of content delivery networks (CDN) — which are optimized to serve static content — your site will become blazing fast all around the globe (mine typically loads in half a second or less) and will cost you close to nothing in terms of money and time. This site’s sole fixed costs are 50 cents per month for DNS services, and deploying an update is one short command-line statement away.

The series

I am planning to share the cool stuff and the gotchas I’ve come across in a series of posts. The topics I’ve got in mind so far are

Stay tuned on my feed and feel free to share comments and thoughts.

The technical details

I’ve built the site you are looking at with the following stack:

  • The Python-based Pelican generates the website content.
  • The source code is under version control by Git.
  • Fabric — which is also Python-based — powers the build and deployment chain.
  • I use Amazon Web Services for DNS services (Route 53), content hosting (S3) and CDN (CloudFront), plus s3cmd as a command-line API to S3 and CloudFront.
  • My theme is based upon Twitter’s Bootstrap style framework.

The LESS sources for the luft·mensch bootstrap theme are here. My Pelican theme started out as a branch of pelican-boostrap3, but it has sinced moved in a different direction, so I moved it into a repository of its own.


comments powered by Disqus