On static sites

📅 Saturday, September 1, 2018

For the past few days I have been working almost exclusively on the site. Starting a new project is always exciting, and so I’m trying to take advantage of that initial momentum as much as possible before it inevitably dies off.

Aside from the excitement for design and content of the blog, however, I also really enjoy using the technology that is powering it. That being a static site generator, specifically Pelican. So I wanted to share a bit about my setup and how it’s working out so far.

First of all, an overview. What a static site generator (or SSG) like Pelican does, is essentially very simple: It takes a directory full of content and a directory of templates and combines the two to create a site as just a flat directory of static files. That can then be deployed on any kind of host you want, from Amazon S3 to a raspberry pi, to a static-site-focused service like Netlify (what this site is using). The final site needs no database or server-side rendering, it’s just served as-is to the user. Good old static HTML/CSS/JS.

While this might sound somewhat limiting, it’s actually more than enough for most websites — and definitely for a blog. Anything you might have wanted to do using, for example, Wordpress you can probably do either at build time using the SSG or using client-side JavaScript: Inserting common features between pages (e.g. a sidebar), minifying CSS, transpiling to JS, are all easy-to-trivial. Anything more dynamic that you might think you need a backend for, you can probably achieve using either an external service (e.g. Disqus for the comments and reactions below), an AWS Lambda function (which Netlify manages for you), or just plain old JavaScript.


So, on to the specifics of my setup. As I said, I’m using a python-based SSG called Pelican. Pelican uses Jinja 2 for its templates which you should be familiar with if you’ve ever used Flask. Building is handled through the pelican command and a python-based config file (pelicanconf.py). Pelican also provides a utility called pelican-quickstart to generate the initial skeleton for the project.

With that said, the file structure for this blog looks like this:

File structure for the blog

The theme I’m using is based on pelican-hyde. I’m maintaining a personal fork of it here, — that is what you’re seeing right now. VSCode makes it very simple to manage both, both the base repo and the submodule show up in the version control tab and provides the same tools for both the root repo and the submodule.


The second most important component in this blog would have to be Netlify. At first it appears like a simple hosting provider with some extra bells and whistles. But it’s so much more than that. It collects CI, Hosting, DNS, HTTPS certificates under one service; and that is just the things I’m using for my simple blog! It also provides authentication, forms, management for AWS lambda functions, and so much more.

All I had to do on netlify for hosting was login to my gitlab account, choose the blog repo, and provide the command to build the site. Netlify then builds the site whenever I push to gitlab. It even detected the dependencies from my Pipfile automatically! Then, I could transfer my domain to Netlify and it generated a let’s encrypt certificate with a single click.

I honestly can’t praise Netlify enough. While it might present issues at bigger scales or edge cases, for my humble blog, it is godsend.


After the little effort I’ve spent setting this up, I can say it was a very successful project. The blog looks as good as I could hope for with the effort I’ve put in and making changes couldn’t be easier. While this is a very small project, I’m sure that static site generators are a much more powerful tool than a lot of people might think. Give one a try for your next project. It might surprise you.