Like vinyl records and mutton chops, it's cool to have static sites again. Their initial coolness from the early days of the web wore off quickly. CGI in 1993 made building dynamic pages possible. Soon, everyone wanted their pages to have a visitor counter, a data entry form, or a search form. WYSIWYG editors like HotDog and FrontPage soon followed that made static web page authoring more accessible to those versed in desktop publishing. Suddenly, anyone could be a webmaster1. The bar was raised for the web developers to differentiate their nifty three-tier architecture from the GeoCities static pages of the hoi polloi. But then, building dynamic sites became easier for more people with new browsers, open source database management systems and web application frameworks, free embeddable services, and social network integration. What's a hacker to do?
This progression in usability and access was inevitable and has made the web a far better experience than the early days of the static web. But static sites are back not because hackers long for some golden age. I'd say they're here because a confluence of factors that still aim to make building and maintaining sites easier.
I'm currently going to business school. A professor of mine has encouraged me to start contributing to a blog again. I've done this a few times beginning and ending over a decade ago, but for me it was always a "go big or go home" project. I found at the time that maintaining an ambitious site got in the way of its primary purpose: write stuff that people will enjoy reading.
But here I go again, writing the first post of a new site. But I'm telling myself that this time will be different. This site was generated using Pelican. I chose the static site generator route for a few reasons:
I wanted to start quickly
Using a static site generator meant that I didn't really have to configure the tool to get started. I had most of those little decisions that add up already decided for me. Things like how files should be organized, how content files are formatted, how URLs should be structured. Sure, the default configs of your more popular CMSs and web frameworks do this too, but the difference with a static site generator is that I could start writing immediately without having to worry about things like unique configurations for my host or troubleshooting third-party dependencies. With a static site generator, I just wrote my first post (this one) and had a pretty good looking site up in minutes.
I wanted something maintainable and hands-off
Ask a longtime WordPress admin about security and prepare to hear about a few hard-learned lessons how some of the most popular community plugins are exploitable. And what were the page load times when they hit the front page of Reddit and they were hosted on a single server with no caching service? It's happened to me. This is my personal site where I may write only a few posts on a sporadic basis. While it's a lot of fun to play with CMSs and web frameworks, I'd rather spend time writing for the site than maintaining it. With a static site generator, I can just focus on writing the content in the human-readable markdown format, not coding in HTML or navigating through multiple admin screens and wrestling with shoddy WYSIWYG web editors. I can then commit to my version control system and upload the generated output files, which I will automate the next time I have writer's block. I have no server-side scripts to process or database connections to make since the files are just HTML, CSS, front-end JS, and images. So if I'm lucky to have HN or Le Reddit Army take an interest in something I post, nginx on an AWS burstable micro instance should be up to the task.
Beautiful responsive design themes are available thanks to the Pelican community. I chose Gilson Filho's Clean Blog theme. I will share my experiments using things like jupyter notebooks, Toyplots, and data visualizations using D3. Those applications and everything else I think I need have static output, are embeddable services, or are processed by the client's browser without needing a server to process a page. Since my audience is small and I'm focusing my time on site content that one-time readers will hopefully find interesting, I am intentionally not implementing engagement activities like commenting systems or social network likes. I may reconsider if I begin to post technical tutorials and readers need help. I could easily add commenting via a service like Disqus, but I'd like to keep this site self-contained with no external service dependencies. If I do implement things like comments or web forms, I will stay very minimalistic and stay true to the spirit of a static gen'd site, even though it may be dynamic. Maybe I'll use JS to mock the commit of a commenter's post, use Flask to capture and process the input on the server, which triggers a rebuild of the static gen pages with comments. Dunno yet.
Why I chose Pelican
I have played with Jeckyll, Octopress, and Metalsmith before. But Pelican is written in my preferred general scripting language, Python, which I'm using more for data analysis too. So I'm more comfortable reading the code if needed.
Pelican appears to have a good assortment of plugins written by the community if I would like to use them. But unlike WordPress and others, the advantage of a static site generator is that I shouldn't have to worry as much about the security of those plugins.
Pelican uses the Jinja2 template engine. There're dozens of template engines out there, but I learned Jinja2 syntax through work with the Flask microframework and I liked it. To me, the generator's choice in template engine is more important than the language in which the generator is written.
Most importantly, I was very pleased that Pelican has well-written documentation that answered every question I've had so far.
After a few hours working with Pelican and as far as I can see, it will be the tool I use for the life of this site. Static site generators are far from a panacea covering the majority of use cases for web sites. But I will continue to keep an eye on how digital media companies like Vox Media and government web sites like the new Healthcare.gov push the capabilities of static sites and build tools around static site generation to make them usable, accessible, and maintainable at scale. It is like you have to go back to move forward. Who knows, maybe in a few years the No-CMS movement will evolve its interfaces to static site generators into something similar to the WordPresses and Drupals of today and it will be "Deja vu all over again"