Static sites enable a good time travel experience
35 comments
·September 2, 2025crazygringo
beeandapenguin
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?
jiehong
Could be useful for company internals sites?
3036e4
Plain text files and version control win again.
DeepYogurt
KISS
marcosdumay
Version control isn't really "simple". That said, neither is plain text nowadays.
It may make sense to change a "S" there for "standard".
jszymborski
Well, it's "relatively simple", as the alternatives either demand a superset of the requirements of static sites or replacements that are more complex.
naniwaduni
Keep it simple, standard,
Amorymeltzer
Not strictly the topic, but don't miss or sleep on the blog (self-)gamification links[1][2], excellent whimsy.
dang
Can I mention HN's custom time travel experience?
https://news.ycombinator.com/front?day=2025-08-31
(available via 'past' in the topbar)
coldfoundry
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.
codazoda
I have a bit of an internal struggle here. I use a site generator too but I struggle with the question, should I? I recently wrote about why I’m writing pure html and CSS in 2025.
https://joeldare.com/why-im-writing-pure-html-and-css-in-202...
jszymborski
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.
EGreg
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”.
cosmicgadget
From the title I thought this was about taking trips down memory lane or seeing historical posts by others. But it seems to be more about seeing design (rather than content) from one's own site in years past. I hope I'm not the only one who would prefer not to see my embarrassing old designs and rather see my archive content rendered in the current (least cringe) template.
Liftyee
My initial thought was that the title was referring to web archive services like the Wayback Machine or archive.is , but the actual topic was equally relevant. I think time travel should work as long as all content is archived / checked in: no reliance on external services (is this the definition of "static site"?)
01HNNWZ0MV43FF
Static site also means no backend. Each request just serves a file unmodified from disk.
null
sharps_xp
is there an decentralized org to ensure that all of the js css we use today remain backward compatible decades from now? or are we just at the whim of these browser vendors?
mananaysiempre
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.
rafram
That's an unfair characterization. WHATWG doesn't version the spec like W3C did, but it's no less backwards compatible. See their FAQ [1], or just load the 1996 Space Jam site [2] in your modern browser.
mananaysiempre
Thus far, WHATWG has mostly behaved benevolently, true. But because they have stayed benevolent for now doesn’t mean we’re going to be any less at their mercy the moment they decide not to. As the recent XSLT discussion aptly demonstrates, both browser vendors and unaffiliated people are quite willing to do the “pay up or shut up” thing for old features, which is of course completely antithetical to backwards compatibility.
AgentME
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.
hypeatei
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.
sedatk
Why do you need such a granular capability, especially when Internet Archive exists. What purpose does it serve?
plorkyeran
> 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.
zoul
A safe rollback on a Friday afternoon is a nice thing for sure :)
curtisblaine
If it builds. Author mentions he/she uses Eleventy, so there's always a possibility that current node / npm versions won't work with some ancient dependencies or with old style peer dependencies. Then it's a long bisection with nvm until you get the right version combo.
luxuryballs
interesting idea: a browser plugin that will cache and upload the final html/css of a page, with some logic to avoid duplicates and “extras” it could be a client side distributed archival system that captures the historical web in always static content
I dunno -- generally speaking, the Wayback Machine is a much better time travel experience than trying to recover a website from an old git commit.
Especially since it's not limited to only sites I've created...
And in this particular case, all the creator was looking for was old badge images, and they'd generally be in an images directory somewhere no matter whether the site was static or dynamic.