How I learned to love link rot
Building and maintaining a personal homepage has been a journey of decades for me. Over the years my web presence has taken many forms, none of which were able to persist in their extant forms once they were more trouble to maintain than to ignore, throw out and replace.
I was unduly influenced by a number of concepts based on my early learning and experience with the web, which I took as a perfect ideal that kept me from just having a fun, maintainable site that I could post interesting things to regularly and not worry about too much when I wasn't doing that.
Some of these concepts you may already be familiar with. They are:
- Cool URLs don’t change
- Server side is better than client side rendering
- Everything on the site must connect with everything else for SEO
- Only database models will support the first three things
Cool URLs don’t change
Out of all of these influences, this one was probably the worst. I wanted so desperately to have my sites be an eternal archive of the web that I would struggle prior to designing or launching any site design for a URL structure that could accommodate any file type, any transformation, and any revision system that I could possibly envision at any point in the future.
Obviously this is not only unsustainable with the pace of technology and transformations, but creates a barrier to starting a new project at all, or getting mired down in the possibilities of different architectures. In some of my iterations I used these unique combinations of numbers and letters to represent individual items so that if the content changed underneath them, their URL would stay the same, worrying more about computers than the human beings that would read the articles and view the pictures.
To get past this I decided to do a best effort structure branching off a core of major categories that were important to me. After a bit of thought I came up with places, hobbies, civics, software, and the self. Everything could be built deeper under those in a category style with simple slugs for path names and if some of them changed over time, it was no big deal. If something was important enough to find, a quick search could lead a visitor to it fast enough.
Server side is better than client side
This is another sentiment from the old days of the web when JavaScript was unstable and it was assumed that every user’s device was slower than the tightly optimized server that your site generation, search, and every other system was running on. Sure this was true for a while but it hasn’t been an issue of concern since the iPhone 5.
Every time I had to design a rendering engine or search utility on my site it became another module or application I would need to maintain and that could be abused by visitors or accidentally overrun by bots. I was constantly thinking about package vulnerabilities and if someone could hijack my site for nefarious purposes because of some plugin I installed to try a cool new feature.
I solved this problem by switching to a static site structure. My laptops at home are easily powerful enough to rebuild several hundred pages and a search index in a matter of minutes and once the files are deployed up to a static web server there's nothing to worry about.
Everything must connect to everything
This was another thought that went along with the Everything2 days leading into Wikipedia, deeply reinforced by the way that early Google operated and really gave search result precedence to heavily interlinked sites with high reputation.
That was fun while it lasted but it turns out I'm not a Wikipedia or an Everything site. The things that I write which have value are the longer essays which take a reader through my thought processes and solve a particular problem. Getting over the urge of thinking I needed my visitors to spend a whole morning clicking around my words was egotistical, and breaking free of it set me up well to write, save, post, and forget.
Only a Database will do
When the web was in its infancy in the mid to late 1990s if you had told someone that the vast majority of sites had to have a relational database behind them to serve content at all, it would have been unfathomable. Most web sites were just a series of files with the .html extension served from a Unix-based file system and the purpose of the web server was to read that file off of the disk, send it to the web browser that asked for it, and then wait for the next request.
Certainly some of the higher level tricks like deep interlinking, making sure that URLs don't change or are redirected to the new content location, and making suggestions and searches are greatly assisted by a relational database, but with a static site builder its possible to have all of these features with nothing but the 90s standard of a handful of files sitting in a specific directory of a Unix web server.