Why Nikola?
Why a static site generator over a dynamic blog engine?
-
I prefer to work in raw HTML because I've been doing it for years, and the markup is readable. For some reason, Markdown, Textile, and reST drive me nuts—mostly because it's easy for me to enter things I don't intend as markup, and when I want to do complex markup, I have to look up the obscure syntax in the documentation. Every. Single. Time.
Most of the blogging engines (such as Wordpress and Drupal ) do allow for directly entering raw HTML, but it always feels like I'm fighting against the grain. Every time I go to compose a post, I have to toggle into a special "HTML entry" mode. One wrong turn and some of the engines will "sanitize" my HTML, reformatting everything. A blogging engine should treat my content as sacred and never try to second-guess (or reformat) what I want.
-
To deploy these dynamic blog engines, it requires a server
with the ability to run code (usually
PHP
but some used
mod_perl
,mod_python
, ormod_cgibin
) and a backing database such as MySQL. Granted, you can find free and low-cost hosting that provides simple PHP/MySQL access, so this isn't a huge hurdle, but it does place additional restrictions on which services you can use. - Some of the cheap/free shared-hosting plans put so many hosts co-located on the same hardware that performance becomes an issue—both database processing and the engine's processing. With a static site generator, there is very little overhead in serving static pages.
- The more dynamic components in play, the more likely it is that vulnerabilities lurk due to the extra exposure. With a static site, far fewer parts are in motion to be attacked so I don't worry about vulnerabilities in PHP, Wordpress, or MySQL.
- Many of the blog engines don't support versioning of the content. I can keep my static site content under revision control with git, Mercurial, Subversion, or a multitude of others.
Why Nikola rather than the other static site generators?
I compared several static site generators, both using a static site generator comparison site and my own testing. Top contenders included the following:
- blosxom (Perl)
- Cactus (Python)
- Jekyll (Ruby)
- Hyde (Python)
- Nikola (Python)
- NanoBlogger (Shell)
- Octopress (Ruby)
As I tested them, I started to develop a list of criteria that mattered to me:
- As a Python developer, I had a bias towards those built in Python. It allows me to poke around under the hood, create patches when I find things I want to change, and gain a deeper understanding of how things worked in the event I hit edge cases.
- Documentation mattered. Several projects had documentation that was incomplete, hard to navigate, or required JavaScript (which prevented the docs from working nicely on one of my e-readers).
- Additionally, some projects seem less than active in their development. According to the static site generator comparison site, some hadn't been updated in months or years while others have had sustained, ongoing development.
- Most importantly, I wanted the ability to compose in HTML fragments rather than being forced to use Markdown, Textile, or reST.
So I ended up settling on Nikola as it's developed in Python, allows me to use HTML fragments, has thorough documentation, and is actively developed.