Static Sites Enable a Good Time Travel Experience

KISS

For some part, W3C is supposed to serve this role, so to the extent that WHATWG controls the web platform, yes, yes we are. Part of the problem is, it’s not clear who exactly is supposed to participate in that hypothetical “decentralized” organization—browser vendors do consult website operators, but on occasion[1] it becomes clear that they only care about the largest ones, whose interests are naturally quite different from the long tail (to the extent that it still exists these days). And this situation is in part natural, economically speaking, because of course the largest operators are the ones that are going to have the most resources to participate in that kind of thing, so money will inevitably end up being the largest determinant of influence.

[1] https://github.com/w3c/webauthn/issues/1255

The engines are open source, no? I don't think we should break websites on purpose but keeping everything backwards compatible does seem untenable for decades to come.

The browsers and standards groups do prioritize backwards compatibility and have done a very good job at it. The only real web compatibility breakages I know of have to do with pre-standardized features or third-party plugins like Flash.

LibreOffice can open AppleWorks files from 1984.

And if it couldn't, you could run these old programs in a VM, and I expect that to continue essentially forever, so I see no future problem viewings these browser files.

Static site also means no backend. Each request just serves a file unmodified from disk.

Hey, thanks for the kind words. I am the author of the second link you shared above. Glad someone liked it.

> Sure I won't have the actual content, but I can see the pages and designs with dummy data. But then I can also load up one of several backups of the sqlite file and...

... so it's useless to anyone except you, then?

Building old code and getting the same result is not always trivial to do.

Potential issues:

- If you have content in a database, can you able to restore the database at any point in time?

- If you code has dependencies, were all the dependencies checked in the repository? If not, can you still find the same version you were using.

- What about your tools, compilers, etc.? Sure some of them like Go are pretty good with backward compatibility, but not all of them. Maybe you used a beta version of a tool? You might need to find the same version of the tools you were using. By the way, did you keep track of the versions of your tools, or do you need to guess?

Even with static websites, you can get into trouble if you referenced e.g. a JS file stored somewhere else. But the point is: going back in time is often much easier with static websites.

(Related topic: reproducible builds.)

A safe rollback on a Friday afternoon is a nice thing for sure :)

> I mentioned this to Varun who asked if I had any screenshots of what it looked like on my website. My initial answer was “no”, then I looked at Wayback Machine but there were not pictures of the badges.

Could be useful for company internals sites?

Was wondering the same thing. Couldn't they just load https://web.archive.org/save/{site_url} once a month in their Github action instead of managing the storage of these images?

I'm not sure how using a static site generator would run counter to any of those points. You can simply generate the same website that you've written by hand.

EDIT: Well perhaps the "build steps" one, but building my Hugo site just involves me running "hugo" in my directory.

The answer is no. You can do this instead: https://community.qbix.com/t/qbix-websites-loading-quickly/2...

See “Static Sites” section. And realize that DNS caching your pages is essentially making your site “static”.

Wow, to be honest I never knew that was there - just got back from the 2017s. Such a cool feature to support on-site without going through third parties, more sites should have official archival support like this!

Thanks for the share.