It's been a long-time desire for me to have a proper website that I can call my own. Like our ancestors who explored foreign lands to settle with their tribes, I too feel that I need to claim some part of the digital terrain.
You might think because of the burgeoning amount of social sites and blog platforms these days, getting a personal website is just a few clicks away. I could sign up for an about.me account or a Wordpress blog and be treated with plenty of attractive personal site features. Yet the truth is, I don't feel that personal with these sites anymore. How can I claim something that's being used by millions of people worldwide to be of my own? Some part of the content may be unique, but that's just as much as the service owners allow you to. Don't get me wrong, I still use some of these sites myself. It's just that they never sway me away from wanting to have a truly personal site.
So I set out to find my own address and space. Being an Indonesian, I was fortunate to be able to register a neat domain (.web.id!) at a very small price. For hosting, I figured NFS would be nice since they don't charge per month but based on usage (which I thought won't be that much anyway).
Initially I thought of installing Wordpress on my site, since it seems to be the easiest way to set up a personal page. But Wordpress has several issues that eventually made me avoid using it:
- I find posting through their UI (and any other blog engine UI) clunky and uncomfortable. The resulting posts are also often different from what I intended them to look like, so I have to spend more time manually editing them before publishing.
- Setting up a complicated blogging engine that I don't completely understand is not my idea of a personal page. I have to be able to understand the underlying logic. Though easy for the end users to use, understanding Wordpress's code base is a different matter. I couldn't afford spending too much time learning PHP just to understand how it works.
- Most importantly, activating a MySQL process on my hosting is too costly for my need (though still relatively cheap). The good thing is, there is a way to avoid using that.
Enter the static site generators.
The idea behind them is simple. They generate the entire html files for a website and the user uploads them to the server for viewing. Unlike most website publishing platforms nowadays, there is no need to establish a database connection and construct complex queries to retrieve data. Everything page a visitor views is a pre-made html file. This principle is as old as the internet itself, but these generators is a relatively recent innovation. What makes them new, is that some can be used as a blog engine much like Wordpress itself. All one needs to do is write the posts, supply the template, and see them processed into a collection of html files ready to be published.
With a database-based blog engine, all data (the posts, the settings, etc.) is stored inside a database. Using a database, one can construct complex queries to view the data in with a given condition. For example, a user can view the latest six posts in a certain post category or view a list of posts based on their popularity if the correct query is entered. In blog engines, these queries are usually constructed using a programming language with PHP being the most well-known. The filtered data is finally displayed to the visitor according to a predefined template.
However, a using database engine comes with drawbacks as well. The most obvious one is speed, because every page needs to be generated on the fly according to a visitor's request. The server has to construct the web page first before sending it to the user, requiring more work compared to simply sending an html file. Given enough users, traffic from the server can slow down significantly. This is often mitigated by using caches, but by definition it is not the actual content that a visitor wants to view at a given time so it's not an ideal solution. Less obvious than speed is security. A lot of website security breaches today exist because of vulnerabilities in the programming logic used to retrieve the data. By exploiting these vulnerabilities, an attacker could access sensitive information or gain control of the server.
Some of these problems are avoided with the use of static sites. With static sites, the server doesn't need to execute any database query, so access time is theoretically faster. Vulnerabilities caused by database access are also gone. I don't know how a site could be less secure if it only serves static pages. There are drawbacks associated with static sites, of course, the biggest being unable to have data-driven websites. Without databases, it is harder to store a visitor's input. A contact form, for example, will be difficult to implement. Comments fall in the same area, although with sites like Disqus, you can get around this limitation. Another disadvantage is the limited way of interacting with your stored data. With database-driven sites, you can perform queries and extract data the way you want to, for example like when you're doing a site-wide search for a certain term. You can still do site-wide searches on static sites, but you'll have to rely on Google or any other 3rd-party provider, much like with comments and Disqus. And finally, you can only update your site if the computer you're using has the static site generator. With database-driven sites, as long as you have internet access, you can log in and update your site.
I decided to go with static sites still, since the disadvantages are manageable compared to the annoyance and cost of using a database-based engine. I don't mind using 3rd-party services to handle comments or search, and I don't feel the need to have ubiquitous access for updating my site anyway.
So I went on a look for the most suitable static site generator. Jekyll and nanoc seemed really tempting given their community activity and documentation. Unfortunately for me, they're based on Ruby and I don't feel like investing time for a new language just to understand their code base. So I started looking for Python-based engines, since I'm mostly familiar with it, and found several interesting ones: Hyde, Pelican, and Blogofile. I had a hard time deciding which one to use among these three, mostly because they're relatively new projects and I couldn't find a clear advantage one has over the other.
In the end, I decided to use Blogofile. I find their documentation to be the easiest to understand among the three and each install comes with a usable plain Blogofile site ready for templating. I had to spend some time understanding Blogofile's template language, but it's been worth it. The result? You're seeing it right now :). This website is entirely generated using Blogofile. Now I can write posts in a simple text editor of my choosing and get the results exactly the way I want, I can track all changes to my site with a version control system since everything is based on text, and I can avoid paying too much for MySQL. Being Python-based, I can peer inside Blogofile's code base and make small tweaks so I get the html file I want. Deployment is done via git (with much help setting it up from this post). With this, I don't have to access the website to post content. Everything is done locally in my computer and updates are only uploaded after the site is built. I just needed to configure the post-receive hook in the remote repository to move all Blogofile-generated files into the public directory of my server and presto, my this site is served.
So, yay for Blogofile! Give it a go if you're considering switching to static.
Addendum 12/07/03: I have stopped using Blogofile and created my own static website generator called Volt. You can get it from PyPI (
pip install volt) or read why I decided to do this here.