I always liked the idea of fast and efficient web pages, especially when those web pages are being served at my expense. I wanted to stay with static pages for two main reasons. First, static pages are cheaper and easier to host and cache. Second, static pages pose little attack surface. The last thing I wanted as a security professional was for a site with my name on it to get compromised because I only look at it twice a year.
I was browsing around for platforms to build my new site on when I heard about this thing Google was working on called AMP HTML. What drew me in was their promise of a fast user experience and a specification designed for being cached. Google was going to cache and prioritize search results for AMP HTML pages and even social networks like Twitter announced plans to implement AMP HTML caching servers. All this meant free bandwidth and geographically distributed caching for my humble site. Perfect.
Sadly, about a year after I reworked my entire site to run on AMP HTML (I had even visually designed it based on Material Design), I realized my decision was not the best. More accurately, my work in security brought me into contact with more privacy-minded people and over time I came to adopt their mindset. I stopped seeing AMP HTML as an open source project and became hung up on the company that sat behind it. A company that over the years has pushed a narrative in cyberspace aimed at destroying privacy with promises of convenience while hiding its true goal of making money by knowing as much about people as legally (not ethically) possible. As the now famous saying goes:
If you're not paying for it; you're the product.
There were also three other reasons for my dissatisfaction with AMP HTML:
In order for AMP pages to be easily cached, the specification requires that all CSS be embedded directly in the HTML. This quickly becomes a problem when you have multiple web pages and you want to adjust your site's theme. Writing all the pages by hand turned out to be a major mistake that lead to inconsistent formatting and unnecessary work.
People, especially those with technical background, are becoming more conscious of the importance of privacy and security and more weary of the power wielded by major tech companies. Even the tech enthusiasts that buy into the mantra of "nothing to hide" have become more cautious of walled gardens that try to lock the user in. The result is negativity towards the AMP HTML platform.
In response to all these points, I decided it was time to move to a different platform for managing my website.
For my new site I still wanted static pages for their cheap hosting, easy caching, and security, but I also wanted a way to be able to write my content in a high level language and have a program automate compilation and deployment. This isn't a new idea by any stretch, so I knew there had to be good tools readily available. After looking at what the blogs I read were using and hearing a few recommendations, I decided to go with Pelican. For those of you who want to statically host blogs, I highly recommend it. The learning curve is manageable and the tools are very comfortable for technical people who already prefer command lines. Pages and articles can be written in Markdown, which should be familiar to anyone who stores code in git repositories. There are also plenty of free and publicly available themes, including the one I'm using for the site right now. I'll stop there before I start to sound like a salesman.
However, while I'm on the topic of plugging software I like, I will also give a quick mention to linkchecker, which I used to find and fix a few links in my past articles to external sites that no longer exist.
So there you have it. The site now runs on Pelican, I like it very much, and hopefully the considerations I listed here will give you ideas to think about.