When all other resources fail me, technical blogs come to the rescue. They provide insight into my problem, clues about the design of a potential solution, and sometimes humor or even an emotional connection. I collect new tech blogs. I devour them.
I write to provide that same benefit, (I try) to help other engineers and to promote free and open software (FLOSS — Free/Libre and Open Source Software). I go back and correct errors, add asides, links, and errata. I work on new content but improve the old stuff too.
Aside from the innumerable benefits, open-source software is vital for a long-lasting website. Closed software will always come to an end. The EOL date for Adobe Flash is 2020 — software that was used on 28.5% of all websites in 2011. Its demise has been met by cheers but people are grappling with the prospect of lost content.
Let's say I plan to revamp my personal website into a brief footprint on the sands of time. What can I do to extend the shelf-life of the second iteration of its production system? What web standards are sure to be kicking as the century turns over and The Clock of the Long Now ticks again.
Static vs dynamic
To define, I'll say that a Jekyll website is static and a Node.js/Express program with database calls is an example of dynamic. A static site generator takes some files, usually text-based, and builds a website into a folder which can be dispersed by any web server. These generators are smart, they build interactive nav bars, minify all of your files, some even make API calls to get up-to-date information.
Gatsby is a static site generator that takes advantage of modern browser features. It uses progressive/responsive image loading, offline access, and provides a React-based design system with a bustling eco-system surrounding it. But if I have some content that I want to provide to the world for a century, Gatsby seems like overcomplicating the problem. It adds many dependencies and is working on accessibility where other generators are accessible by default because they're flat sites.
At the very worst, a static site generator will generate HTML files which can simply be read by the human eye. They can be archived and left. Content management systems like Blogspot or SquareSpace generate a pile of JavaScript which pulls your files from a propriety location, likely without a published spec.
Markdown
Markdown sounds like the tool for the job (but only if a spec is included). Since its invention Markdown has empowered READMEs, blogs, forums, and more. I use it to drive a number of things including this article. However, it exists under a kind of living tree doctrine. Services add their own features and interpretations (which is a good thing) but for our century-long plan, we'll need a document that explains how the markings should be interpreted to display the content in its originally planned manner.
I think of the oak beams in the ceiling of College Hall at New College, Oxford. Last century, when the beams needed replacing, carpenters used oak trees that had been planted in 1386 when the dining hall was first built. The 14th-century builder had planted the trees in anticipation of the time, hundreds of years in the future, when the beams would need replacing. Did the carpenters plant new trees to replace the beams again a few hundred years from now?
— WIRED SCENARIOS: THE MILLENNIUM CLOCK DANNY HILLIS
Maintenance
An ideal software stack might have one dependency, a run-time from a too-big-to-fail programming language. Perhaps a static site generator written in pure Python. Maybe even that is overcomplicating it. Some blogs that I enjoy are created via Makefile! The Lindy effect is a theory that means the life expectancy of technology is proportional to its current age. I would like to avoid revamping every five years — or sixteen times in this coming century. Maybe the ideal technology is in fact from a decade ago and is not present in my lexicon.
Dead links are a problem but a link crawler can be run on a cron job. I use a similar method and go back to correct links to resources that have moved — or I use an alternative resource. If a source disappears entirely, I'll write a footnote. I know some writers back up all of their sources to create a self-contained web — which is a noble, librarian-like goal.
Continuous improvement of the lightweight design and the content will be necessary. Or we could just write as professors do, take Peter Norvig's article on solving sudoku with Python. It's written like an RFC spec and apart from the two graphs is replicable by a century-old typewriter.
Content that mellows
Through repetitive practice, my writing has and will improve over time. I don't want to leave my old articles to rot. Posts about specific technologies can be locked (with minor trimming) but there are others which aim to be timeless. I wonder about a schedule where content is re-edited and parts re-written every X months. Performing a quick readthrough of many of my old articles leads to me dropping a resource here and an extra example there. Evergreen.
It's at this point that proper version control becomes important as changing an article can change the meaning, which can invalidate an offsite citation. Providing access to different versions of articles sounds non-trivial for a static site generator. It sounds like Wikipedia's system.
If you are interested in solving any of these problems with me you should contact me!
Tech blog recommendations
Join 150+ people signed up to my newsletter on programming and personal growth!
I tweet about tech @healeycodes.
Top comments (29)
Here's the first website I ever published. It's lasted 21 years.
home.the-wire.com/~pnaomi/
The only decay here is that the blink tags don't work anymore.
Pure HTML. Just sayin'...!
I miss the web looking like that!
Awesome site. Thanks for sharing 👍
I was waiting for some star wars intro titles coming up from the bottom xdd
Doesn't open on my machine (Android).
Oh noes... I think The Wire may have finally killed the old dialup user websites.
You know, it's true what they say, you can never truly go back /home.
Found it on The Wayback Machine! HAhahaha my stupid website will never die!!!111one
web.archive.org/web/20030625055541...
This is great! Big throwback vibes 👍
I believe this can be achieved by two ways.
1) Store your website content in a non digital format. Example: print book that is saved in a public library.
2) Have enough funds to pay for a service that will last for 100 years. Maybe using torrents or ipfs or archive.org?. If your content bring some value to enough people, someone will make a backup.
I love the non-digital format idea and I wonder how it could be automated.
I suppose I'm assuming that I myself will (🤞) be living for the next 100 years to maintain this website. So I'm more looking to ease my maintenance and having some fun with long-term thinking. The archival angle is important if I were to suddenly go offline!
Several static site generators are also able to produce PDF or txt versions of the content. I used Sphinx successfully in a similar context.
I think this is a very important topic. I wrote about it a couple years ago tedbergeron.github.io/2016/08/22/P...
I agree with keeping the content as text (Markdown/AsciiDoc) and using a process to convert it to static HTML.
But how do you ensure (pay) it will be hosted a hundred years from now? We have the Internet Archive archive.org/ but maybe we need more that that. Some public commons that is preserving static content forever.
Markdown with front matter might be one of the best export formats for both human and semantic meaning.
But how do I export WordPress like so?
Search for "wordpress export to markdown file" and you'll find solutions from WordPress plugins to projects like github.com/lonekorean/wordpress-ex... "Converts a WordPress export XML file into Markdown files. Useful if you want to migrate from WordPress to a static site generator (Gatsby, Hugo, Jekyll, etc.)."
This is so interesting.
At this point I would settle for just stability for a few years. I maintain a large portfolio of personal & client sites - so far using my own framework & cms has provided close to 8 years of stability- no updates needed despite new versions of PHP.
But I want to start using a modern framework like Laravel for future projects, but I dread a future where every 6 months or so I have to migrate a long list of sites.
It's a trade-off: stability vs features/modernization.
Oh my goodness! I had the same thought!
I had the idea of sharing songs from uncommon countries. So I did. Now I have hundreds of songs lying around on social media posts to be listed or organized in some way. I am big fan of FLOSS, so I wanted anything FLOSS + which should last for a long time, even if I don't get to maintain it.
So I chose GitLab Pages. GitLab is open source and a popular option that should be there for a long time. Plus, I get to make my site open for anyone to fork and make their own playlist if they want to. So I made a site with it's source code available here.
I have a CSV file which I add every song to it. It gets read and the playlist is played automatically when someone goes to the playlist, like this. It even has sub playlists based genres and listening habits, everything done in pure HTML-CSS-JS!
Currently it is Bengali language, but I am planning to localize it.
Interesting!
I also read this recently on the subject: jeffhuang.com/designed_to_last/
I read at a glance and seems like a great guideline to follow. Thanks. Will read later.
I'm convinced the future is made of reworking our computer-to-human relationship. Ultimately, we will deal with an assistant (Jarvis), so you might want to invest in some technology like Heek, the chatbot that build a website by chatting with you. (Human) manual programming is dead in 40-60 years imo #elonMuskStyleBet.
Chatbots have a looooong way to go.
I think chatbots are actually a thing in the sense that they are not told to do more than we teach them.
However, intelligent (or, more like comprehensive) artificial assistants can build the next centuries as our fast, efficient, and effortless way to access and manipulate data. Imagine you can book an appointment for your daughter horse class while you ask your assistant to bring your tesla in front of your job location in 30mins and it figures out depending the real time traffic at which time to go after having charged enough to bring you to this dinner it booked for you because he remembers your wife's birthday (gone too far on this one 😂) you got the idea! I trust this is where we are going, maybe not in the next 30 years...
It was expected to happen somewhere around 2000 year. But didn't. :D
I think you can split this problem two ways. Something that I can go back to the same url in 100 years and something that I can keep building in 100 years.
I think Gatsby is a great choice and will be able to run for a really long time, likely 100 years. Since it can be statically hosted anywhere it would be easy to pivot hosting providers as they go in and out if business.
Now can you build it and keep adding content in 100 years. It's not very likely that you would. npm, node, and the whole ecosystem will not likely last 100 years as it is now. But if you have all of your content in markdown it will be easy to pivot to the next big thing when necessary.
This will continue to be a big problem moving forward, that being the short shelf life of most things online. Seems counter-intuitive to how we were always told about how things on the internet would last forever, but I really enjoyed your article :)
What language are you proposing? Maybe in 100 years everybody speaks Chinese? Or Dutch? Related Radiolab episode. Too short conclusion: visual language and visual (icon based) communication.
Markdown is not good for that task, it does not have official spec,
theres a page that GitHub put to document their own incompatible implementation, and most implementations are not based on it,
most implementations outthere are different and implement half the format.
ResTructuredText (AKA RST), does have an official spec,
very detailed and technical, is more expressive than MarkDown,
some parsers have very Draconian errors, but thats not RSTs fault,
and the extra stuff is implemented as Directives, that also are documented.
ODT (AKA LibreOffice Document) is an ISO Standard and has Official Spec, so is a good candidate, is XML and verbose as hell but can be pretty-printed.
JSON pretty-printed is also very good, maybe combined with some RST formatting.
Latex is also good alternative, has official spec, but not ISO standard tho,
if you use CTAN stuff (like the standard library of Latex), it will render,
it will be the only that lets you write some math and science stuff.
I hope when they finish and stabilize WebAssembly to push it into an ISO standard.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.