Paul's Internet Landfill/ 2019/ Self-Contained Static Sites

Self-Contained Static Sites

I am working on a secret project to publish RSS feeds for Watcamp and other sites. I decided I needed a simple set of web pages with links and instructions, but I did not want to maintain a complicated page. I wanted to make some Markdown files, hit publish, and get on with my life. What a maroon.

Requirements

Things did not turn out quite like that. Along the way I discovered I wanted more out of my website:

Do these seem like reasonable requirements? I thought they were, but now I am not sure.

Static Site Dependencies

My inclination was to make a static site. The theming was the hard part -- if I wanted a 1995-style website I could have just written Markdown and processed it with Pandoc. I thought using a static site generator was the way to go. I restricted my search to those that supported Markdown and were written in Python, but there still were too many options available. I read about some of the market leaders and decided that Pelican would probably be "good enough". So far I am regretting that decision a little -- Pelican really wants to see the world in terms of blogs -- but I am probably sticking with it for now.

Then I had to find a theme. There is a Pelican Themes project with an associated Github repo. I started (non-exhaustively) looking through options, and discovered some categories:

I decided to go with a non-ugly theme that would would work with mobile and text-based browsers. Then I had to make a decision between those with external dependencies and those with not.

Here is the epiphany of this exploration: everything sucks. If you download local copies of the libraries you need, then your site is more portable, but you are hosed when there are security fixes. If you point to external web resources, then you are dependent on those external resources not breaking.

I realized that although static sites are static, they are not self-contained, and they still have to be maintained. If there is a security problem in one of your libraries, you should update that library (either by pointing it to a different version or downloading that different version). Static sites are fragile in a way that I was not expecting.

Longevity

When you visit websites on the Wayback Machine, you see a lot of broken websites. Some websites have rendering problems. Very few of them are secured with HTTPS. Some are not indexed at all. But the worst problem is that the websites point to resources (such as images) that were originally posted on some other server, and are no longer available. That is really irritating.

In my experience modern browsers are pretty good at rendering ancient HTML. They are terrible at rendering ancient Java and probably increasingly worse at rendering Flash.

I doubt this Secret Project is going to amount to much or that anybody will want to visit it in 20 years, but aesthetically I decided the lesser evil would be to bundle libraries within the theme rather than depending on external CDNs. I acknowledge that this is still an evil.

Google is Fickle

Here's my real concern: the Web depends upon Google for its web design, and I am not convinced that Google can be trusted. The world has decided to use Google as its source for web fonts, but the FAQ insists that Google does not use the fonts repo for heavy surveillance. If I believe that, then I am not sure I believe they have an interest in keeping the service running in the long term. So now I should expect that the fonts used in my beautiful themes will disappear?

Over the years, I have learned that Google has few compunctions about killing its products. Notoriously it killed Google Reader, but it also killed Google Code, Google Video, and the goo.gl web shortener. Some of that content is still accessible, but the URLs have changed for Google Code and Google Video. Why should I believe that Google Fonts will be around in 10 years? Why should I believe that the URL mechanism will remain the same.

The same question goes to the CDNs that are hosting third party libraries. It looks as if unpkg is maybe supported by CloudFlare? What happens if CloudFlare goes away? Do we expect it to stick around forever? Do we expect the Wayback Machine to archive all of CloudFlare?

Tradeoffs

I decided to take a good-looking theme with as few dependencies as possible, and internalize what I could. I ended up using the Gum theme, which has locally-archived copies of jQuery and something called Modernizr, depends on some locally-archived framework called Gumby (which has been abandoned by its developers, natch).

The theme depended upon a font hosted at Google, so I discovered Google Webfonts Helper and used it to download a font bundle, which I put on the site.

I tried turning off Javascript for the Gum theme, but then the hamburger menu didn't work, so I gave up.

At the end of the day I had a static site with a responsive theme (that will look horribly dated two years from now) that was entirely self-contained.

The next step would be getting rid of Javascript, but I do not think I have the motivation to pursue that. There is a CSS-only framework called Bulma that looks interesting, but that is future work.

Lessons

Appendix A: Pelican themes

My shortlist of Pelican themes that have promise are as follows:

This is not a comprehensive list, but if you are trying to navigate pelicanthemes.com for some options, you might start here.

Appendix B: Why not ikiwiki?

So this blog is created using ikiwiki, which is itself a static site generator. I plan to keep using it for my blog, but it is kind of a dead end for new projects. For one thing it is written in Perl; for another it is largely unmaintained; for a third I would have to learn enough theming to make a responsive theme for it.