HTML5Up

When I originally registered the domain carteryagemann.com I imagined it would be a single static page summarizing my professional career; an eye catch for recruiters and peers searching my name on the internet. I wanted a place for bragging that I would have complete control over and not be restricted by the cookie-cutter molds set by social networking sites. A few months later I was asked to write blog articles for Syracuse University's engineering college and suddenly my website was no longer a sole page. As much as I liked my HTML5Up design, I needed new templates. I also have to admit that the JavaScript my site originally used was slow at times.

AMP HTML

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:

Mandatory JavaScript

As someone who values security and privacy, I try my best to make websites that are functional even when the user disables active content (JavaScript, Flash, etc.). If a site wants to use JavaScript to make some parts prettier (e.g. syntax highlighting code) or save bandwidth (e.g. AJAX), that's fine. On the other hand, I find it very rude and unethical when a site won't even display a single image or line of text until the user executes JavaScript from 30+ sources (news sites are particularly notorious for this). JavaScript is code, code can be malicious or invasive (e.g. JavaScript exploit kits for installing ransomware), and just like how I wouldn't hand someone I just met a self-signed Windows executable and ask them to run it, a user shouldn't be forced to execute JavaScript upfront just to see what the site is about. This is even more true when that JavaScript is heavily compressed and obfuscated.

In-line CSS

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.

Public Opinion

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.

Additionally, as the AMP HTML specification evolves, people both on the technical and nontechnical sides are becoming confused.

In response to all these points, I decided it was time to move to a different platform for managing my website.

Pelican

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.