-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Hm interesting, I read over your 7 guidelines [1] and I would say I agree 50%.
So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it -- I agree with this, although to me I would use the words "standards" and multiple implementations. The linked article doesn't appear to emphasize this.
- Return to vanilla HTML/CSS
Again I feel the relevant issue is "standards", multiple implementations, and the fallback option of "old code" like GNU coreutils (i.e. taking advantage of the Lindy Effect). Not just just HTML/CSS (which certainly meet all of those criteria.)
I thought about this when designing https://www.oilshell.org/ and the toolchain
- The site started in Markdown but is now standardized on CommonMark [1], which has multiple implementations. So I don't see any reason to stick to HTML/CSS.
- The tools are written in Python and shell [2]. Both languages have multiple implementations. (Ironically, Oil is a second implementation of bash! My bash scripts run under both bash and Oil.)
- Python and shell rely on Unix, which is standardized (e.g. Linux and FreeBSD have a large common subset that can build my site).
This is perhaps unconventional, but I avoided using languages that I don't know how to bootstrap like node.js (has a complex JIT and build process), Go (doesn't use libc) or Rust (complex bootstrap).
On the other hand, C has multiple implementations, and Python and shell are written in C, and easy to compile. I'd say Lua also falls in this category, but node.js doesn't.
I feel like this is at least 60% of the way to making a website that lasts 30 years. The other 40% is the domain name and hosting.
This is a pretty a big site now, you can tar a lot of it up and browse it locally (well it's true you may have to rewrite some self links).
Of course, this is my solution as a technical user. If you're trying to solve this problem for the general public, then that's much harder.
[1] https://www.oilshell.org/blog/2018/02/14.html
[2] https://www.oilshell.org/site.html
- Don't minimize that HTML
Mildly agree if only because it's useful to be able to read HTML to rewrite self links and so forth. Tools don't need it, but it's nice for humans.
- Prefer one page over several
If you're allowed to use Python and shell to automate stuff, then this isn't an issue. I suppose another risk is that people besides me might not understand how to maintain my code. But I don't think it needs to be maintained -- I think it will run forever on the basis of Unix, shell, and Python. Those technologies have "crossed the chasm", where again I think the jury is still out on others.
- End all forms of hotlinking
Yes, my site hosts all its own JS and CSS.
- Stick with native fonts
Yes, custom fonts have a higher chance of being unreadable in the future. I just use the browser's font preference to avoid this issue. It's more future proof and in keeping with the spirit of the web (semantic, not pixel perfect).
- Obsessively compress your images
Agree
- Eliminate the broken URL risk
I think too few people are using commodity shared hosting ... I've been meaning to write some blog posts about that. I use Dreamhost but NearlyFreeSpeech is basically the same idea. It's basically a Unix box and a web server that somebody else maintains.
The key point is that it has multiple implementations. It is a de facto standard. The main difference between a tarball of HTML and a shared hosting site is that say "index.html" is always respected as the root.
So I expect Heroku and similar platforms to come and go, but the de-facto standard of a shared hosting interface will stay forever. It's basically any Unix + any static web server, e.g. I think OpenBSD has a pretty good httpd that's like Apache/Nginx for all the relevant purposes.
So I guess this is adding sort of a programmer's slant to it. To be honest it took me a long time to be fluent enough in Python and shell to make a decent website :) Markdown/CommonMark definitely helps too. I had of course made HTML before this, but it was the odd page here and there. Making a whole site does require some automation, and I agree that lots of common/popular tools and hosting platforms will rot very quickly. (and like you I've seen that happen multiple times in my life!)
It comes down to the person running the website has to care. That's it. It doesn't matter how simple it is if the person doesn't care.
In my own case, I've been running my own website for 24 years now [1]. The URLs I started out with have remained the same (although some have gone, and yes, I return 410 for those) and the technology hasn't changed much either (it was Apache 24 years ago, it's still Apache today; my blog engine [2] was a C-based CGI program, and it's still a C-based CGI program. The rest of the site is static, and there's no Javascript (except for one page). I can see it lasting at least six more years, and probably more. But I care.
[1] Started out on a physical server (an AMD 586) and a few years later on a virtual server.
[2] https://github.com/spc476/mod_blog