Tags: static

Speaking of serendipity, not long after I wrote about making a static archive of The Session for people to download and share, I came across a piece by Alex Chan about using static websites for tiny archives.

The use-case is slightly different—this is about personal archives, like paperwork, screenshots, and bookmarks. But we both came up with the same process:

I’m deliberately going low-scale, low-tech. There’s no web server, no build system, no dependencies, and no JavaScript frameworks.

And we share the same hope:

Because this system has no moving parts, and it’s just files on a disk, I hope it will last a long time.

You should read the whole thing, where Alex describes all the other approaches they took before settling on plain ol’ HTML files in a folder:

HTML is low maintenance, it’s flexible, and it’s not going anywhere. It’s the foundation of the entire web, and pretty much every modern computer has a web browser that can render HTML pages. These files will be usable for a very long time – probably decades, if not more.

I’m enjoying this approach, so I’m going to keep using it. What I particularly like is that the maintenance burden has been essentially zero – once I set up the initial site structure, I haven’t had to do anything to keep it working.

They also talk about digital preservation:

I’d love to see static websites get more use as a preservation tool.

I concur! And it’s particularly interesting for Alex to be making this observation in the context of working with the Flickr foundation. That’s where they’re experimenting with the concept of a data lifeboat

What should we do when a digital service sinks?

This is something that George spoke about at the final dConstruct in 2022. You can listen to the talk on the dConstruct archive.

When I went up to London for the State of the Browser conference last month, I shared the train journey with Remy.

I always like getting together with Remy. We usually end up discussing sci-fi books we’re reading, commiserating with one another about conference-organising, discussing the minutiae of browser APIs, or talking about the big-picture vision of the World Wide Web.

On this train ride we ended up talking about the march of time and how death comes for us all …and our websites.

Take The Session, for example. It’s been running for two and a half decades in one form or another. I plan to keep it running for many more decades to come. But I’m the weak link in that plan.

If I get hit by a bus tomorrow, The Session will keep running. The hosting is paid up for a while. The domain name is registered for as long as possible. But inevitably things will need to be updated. Even if no new features get added to the site, someone’s got to install updates to keep the underlying software safe and secure.

Remy and I discussed the long-term prospects for widening out the admin work to more people. But we also discussed smaller steps I could take in the meantime.

Like, there’s the actual content of the website. Now, I currently share exports from the database every week in JSON, CSV, and SQLite. That’s good. But you need to be tech nerd to do anything useful with that data.

The more I talked about it with Remy, the more I realised that HTML would be the most useful format for the most people.

There’s a cute acronym in the world of digital preservation: LOCKSS. Lots Of Copies Keep Stuff Safe. If there were multiple copies of The Session’s content out there in the world, then I’d have a nice little insurance policy against some future catastrophe befalling the live site.

With the seed of the idea planted in my head, I waited until I had some time to dive in and see if this was doable.

Fortunately I had plenty of opportunity to do just that on some other train rides. When I was in Spain and France recently, I spent hours and hours on trains. For some reason, I find train journeys very conducive to coding, especially if you don’t need an internet connection.

By the time I was back home, the code was done. Here’s the result:

The Session archive: a static copy of the content on thesession.org.

If you want to grab a copy for yourself, go ahead and download this .zip file. Be warned that it’s quite large! The .zip file is over two gigabytes in size and the unzipped collection of web pages is almost ten gigabytes. I plan to update the content every week or so.

I’ve put a copy up on Netlify and I’m serving it from the subdomain archive.thesession.org if you want to check out the results without downloading the whole thing.

Because this is a collection of static files, there’s no search. But you can use your browser’s “Find in Page” feature to search within the (very long) index pages of each section of the site.

You don’t need to a web server to click around between the pages: they should all work straight from your file system. Double-clicking any HTML file should give a starting point.

I wanted to reduce the dependencies on each page to as close to zero as I could. All the CSS is embedded in the the page. Likewise with most of the JavaScript (you’ll still need an internet connection to get audio playback and dynamic maps). This keeps the individual pages nice and self-contained. That means they can be shared around (as an email attachment, for example).

I’ve shared this project with the community on The Session and people are into it. If nothing else, it could be handy to have an offline copy of the site’s content on your hard drive for those situations when you can’t access the site itself.

The Demise of the Mildly Dynamic Website

It me:

Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.

This rings sadly true to me:

Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

Also, I never thought about “serverless” like this:

Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.

The Baked Data architectural pattern

Simon describes the pattern he uses for content sites to get all of the resilience of static site generators while keeping dynamic functionality.

Introducing Astro: Ship Less JavaScript

In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.

YES!

When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.

That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).

This is a tagline I can get behind:

Ship Less JavaScript

Grow the IndieWeb with Webmentions | Amber Wilson

Amber describes how she implemented webmentions on her (static) site. More important, she describes why!

Rendering Spectrum | CSS-Tricks

Sensible advice from Chris:

So what’s the best rendering method? Whatever works best for you, but perhaps a hierarchy like this makes some general sense:

1. Static HTML as much as you can
2. Edge functions over static HTML so you can do whatever dynamic things
3. Server generated HTML what you have to after that
4. Client-side render only what you absolutely have to

SofaConf 2020 - a technical write-up | Trys Mudford

Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).

I love the fact that anyone on the Clearleft events team can push to production with a Slack message.

I also love that the site is Lighthousetastically fast.

Get Static – Eric’s Archived Thoughts

Performance matters …especially when the chips are down:

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static. I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.

It was Indie Web Camp Brighton on the weekend. After a day of thought-provoking discussions, I thoroughly enjoyed spending the second day tinkering on my website.

For a while now, I’ve wanted to add maps to my monthly archive pages (to accompany the calendar heatmaps I added at a previous Indie Web Camp). Whenever I post anything to my site—a blog post, a note, a link—it’s timestamped and geotagged. I thought it would be fun to expose that in a glanceable way. A map seems like the right medium for that, but I wanted to avoid the obvious route of dropping a load of pins on a map. Instead I was looking for something more like the maps in Indiana Jones films—a line drawn from place to place to show the movement over time.

I talked to Aaron about this and his advice was that a client-side JavaScript embedded map would be the easiest option. But that seemed like overkill to me. This map didn’t need to be pannable or zoomable; just glanceable. So I decided to see if how far I could get with a static map. I timeboxed two hours for it.

After two hours, I admitted defeat.

I was able to find the kind of static maps I wanted from Mapbox—I’m already using them for my check-ins. I could even add a polyline, which is exactly what I wanted. But instead of passing latitude and longitude co-ordinates for the points on the polyline, the docs explain that I needed to provide …cur ominous thunder and lightning… The Encoded Polyline Algorithm Format.

Go to that link. I’ll wait.

Did you read through the eleven steps of instructions? Did you also think it was a piss take?

1. Take the initial signed value.
2. Multiply it by 1e5.
3. Convert that decimal value to binary.
4. Left-shift the binary value one bit.
5. If the original decimal value is negative, invert this encoding.
6. Break the binary value out into 5-bit chunks.
7. Place the 5-bit chunks into reverse order.
8. OR each value with 0x20 if another bit chunk follows.
9. Convert each value to decimal.
10. Add 63 to each value.
11. Convert each value to its ASCII equivalent.

This was way beyond my brain’s pay grade. But surely someone else had written the code I needed? I did some Duck Duck Going and found a piece of PHP code to do the encoding. It didn’t work. I Ducked Ducked and Went some more. I found a different piece of PHP code. That didn’t work either.

At this point, my allotted time was up. If I wanted to have something to demo by the end of the day, I needed to switch gears. So I did.

I used Leaflet.js to create the maps I wanted using client-side JavaScript. Here’s the JavaScript code I wrote.

It waits until the page has finished loading, then it searches for any instances of the h-geo microformat (a way of encoding latitude and longitude coordinates in HTML). If there are three or more, it generates a script element to pull in the Leaflet library, and a corresponding style element. Then it draws the map with the polyline on it. I ended up using Stamen’s beautiful watercolour map tiles.

That’s what I demoed at the end of the day.

But I wasn’t happy with it.

Sure, it looked good, but displaying the map required requests for a script, a style sheet, and multiple map tiles. I made sure that it didn’t hold up the loading of the rest of the page, but it still felt wasteful.

So after Indie Web Camp, I went back to investigate static maps again. This time I did finally manage to find some PHP code for encoding lat/lon coordinates into a polyline that worked. Finally I was able to construct URLs for a static map image that displays a line connecting multiple points with a line.

I’ve put this maps on any of the archive pages that also have calendar heat maps. Some examples:

• Everything from August 2019
• Notes from July 2018
• Links from June 2017
• Photos from October 2014
• Journal entries from December 2012

If you go back much further than that, the maps start to trail off. That’s because I wasn’t geotagging everything from the start.

I’m pretty happy with the final results. It’s certainly far more responsible from a performance point of view. Oh, and I’ve also got the maps inside a picture element so that I can swap out the tiles if you switch to dark mode.

It’s a shame that I can’t use the lovely Stamen watercolour tiles for these static maps though.

mathieudutour/medium-to-own-blog: Switch from Medium to your own blog in a few minutes

Following on from Stackbit’s tool, here’s another (more code-heavy) way of migrating from Ev’s blog to your own site.

JAMstack? More like SHAMstack. | CSS-Tricks

Chris makes the very good point that the J in JAMstack isn’t nearly as important as the static hosting part.

I also pointed out to Phil recently that the M (markup) is far more important than the J (JavaScript), which is there to enhance the M. So I suggested that the acronym be updated accordingly:

MAJstack!

This is my maj.

Medium | Stackbit

This is very handy! Export your data from Ev’s blog and then import it into a static site generator of your choice.

You may have noticed the recent movement of people looking to get off Medium. Most of us are motivated by a desire to own our content, have data portability and get more control over how/where our content is displayed and monetized. Most importantly many of us consider our blog/site to be a core part of our online identity and while Medium offers a fantastic writing experience it sacrifices other important values. Luckily there’s a modern approach to running your blog which aligns with these ideals, its called the JAMstack and its all around us.

Sergey | the little SSG

Trys has made YASSG—Yet Another Static Site Generator. It’s called Sergey (like SSG, see?) and it does just one thing: it allows you to include chunks of markup. It’s Apache Server Side Includes all over again!

Kick the tyres and see what you think.

indiekit | An IndieWeb publishing toolkit

Paul is making a micropub endpoint for static sites—very cool!

StaticGen | Top Open Source Static Site Generators

There are a lot of static site generators out there!

Mavo: A new, approachable way to create Web applications

A really interesting new project from Lea that aims to put dynamic sites within the reach of everyone. The emphasis is on declarative languages—HTML and CSS—no JavaScript knowledge required.

Lea has also written an introductory article on Smashing Mag.

Setting up CloudFront and TLS (HTTPS) with Jekyll – olivermak.es

Remember when I mentioned that you can get free certificates from Amazon now? Well, Oliver has written an in-depth step-by-step description of how he got his static site all set up with HTTPS.

More of this please! Share your experiences with moving to TLS—the more, the better.

Enabling Webmentions in Jekyll, From the Notebook of Aaron Gustafson

Aaron documents the process of adding webmention support to a static site. He came with an ingenious three-tiered approach:

It’s been a pretty fun mini-project. In the end, I created a useful bit of kit that provides three distinct experiences:

1. Static webmentions collected when the site was generated form the baseline experience;
2. JavaScript-enabled browsers get any webmentions that were published since I last generated the site; and
3. JavaScript-enabled browsers with WebSockets support get real-time updates with any webmentions that are published after the page loads.

New service: WebMentions for static pages

Want to implement webmentions but you’re using static pages a-la Jekyll? No problem. Pelle’s got you covered.