Recently, I have been thinking about how to organize the things I've been doing over the last years. I happened to post a little article on my blog from time to time, but I feel that this format becomes a bit messy as time goes by, and that it doesn't fit well for all kind of content. So time to think about how to improve the situation.
Since 2013, I have been using Pelican to generate static HTML pages from text files using the Markdown syntax. And after looking around at what others are doing, I still very much like this idea. All the computation required to generate the HTML documents interpreted by our browsers is actually performed only once, during the site/blog generation phase (and not each time a user is requesting a page). The static files can then be uploaded anywhere, and be served without wasting precious computing power and energy. Vladimír Vondruš explains a similar point of view quite well, Joanna Rutkowska as well.
I like writing (and reading) text files with my favorite editor. And these last years, a few text formats and tools have appeared, allowing the translation of 'easy-to-read, easy-to-write plain text' files to HTML. Some people prefer reStructuredText, I have a (visual) preference for Markdown, though both are very good fits for the purpose of writing content for websites.
Regarding the generation of the website/blog, a lot of tools are available in the wild, like Jekyll, Pelican and Hugo, respectively written in Ruby, Python and Go. I haven't seen any unique feature in these tools, so any of them should work for our use case. Well, there are some little differences though: Jekyll has a larger community, as it seems to be the most popular static blog generator. That is a first reason to not use Jekyll ; ). Also I'm more familiar with Python, which naturally leads me towards Pelican. A lot of themes are available for Pelican as well as for the other sites generators. The choice of the theme may also influence the choice of the tool.
Website versus Blog
As part of the current reflection was the idea of improving the organization of my things. I like the idea of being able to structure my content using folders and sub-folders, like most websites are structured, rather than a pure blog-like chronological setup. However, most of the tools for generating static pages are primarily targeting blogs. Jekyll documents the ability to organize pages into sub-folders out of the box, while Pelican seems to provide that feature through (currently not so well documented) customization of its configuration file. That said, Pelican exposes a notion of category, that can be used to organize blog articles; filesystem folders can be used to represent this organization. There's also the notion of pages for non-temporal content. So by default (i.e without customization), Pelican allows 1-level folders for articles, plus direct access to 'special' pages. These features alone probably cover most of my needs for the near future.
Eventually, I discovered Vladimír Vondruš m.css Pelican theme. It has a clean and simple look and feel, is well documented and can be extensively customized. The author uses it to generate his own websites. This 'theme' kind of transforms Pelican into a generic website generator, at the cost of crafting Pelican's configuration file. I'm wondering to what extent this customization could be simplified, by adding a better support for sub-folders into Pelican. Anyway, Pelican + m.css is the perfect match for my use case for the foreseeable future.
A word on GitHub Pages, which is a free service from Github, allowing to publish one static website per account; it uses Jekyll under the hood. That is a decent place to start, but I don't really like the idea of being too tied with a commercial organization and provide more personal data to a web giant. Besides, this limits the choice of the tools one can use for their personal blog or website.
I'll rather move towards the use of commodity services, that I'll be able to change at any moment if one of the service providers is down or changes its policy. Two services are actually required: