Organic, Homegrown HTML

2021-02-12

Despite increasing leniency on frameworks being the only way to build for the web, hand-written HTML never disappeared and I feel is still a perfectly suitable way to build a personal website.

This notion was spurred on a few weeks ago when I decided to do some decluttering on my machine: removing old files, temporary scratchpads, and the like…and then I got to my site directory. 875MB. Despite only containing a few blog posts (read: text files), my site was taking up more space than every Wikipedia article on Computer-Science combined, with 200MB+ still to spare. Where were these hundreds of megabytes coming from?

As it turns out node_packages was the root of the problem. Dependencies that required other dependencies. Packages so far removed from my end-point there was no way to even guess what purpose they served. As much as I enjoyed using GatsbyJS - my framework of choice, I couldn’t carry on with a system that was in excess of my needs to such a degree.

With this - and a spare few days - I decided to start from scratch, plain HTML and CSS from the ground up. After a day or two I’d managed to piece together a site generator using various Bash scripts comprising of existing Unix commands that took care of almost all the functionality I had before. I was frankly amazed at how seamless the process was with programs like sed and grep being more than capable enough to blaze through converting pages, updating changes, and applying dynamic styling; All with no amorphous packages or hidden boilerplate, just tried-and-true HTML and a Unix toolbox with over 40 years of reliability.

Looking back I wondered why I’d ever thought using a framework was the right choice to begin with: The constant updates, packages fulfilling unknown roles, and boilerplate handling features I’ll never use. I was left wondering how a system like this could survive over time.

I’m reminded of a comment I saw on Hacker News stating that:

There’s really too much for us to handle, so we build tools and services to help us manage all that information streaming towards us. But what we’ve forgotten is that we don’t need to manage all the information out in the world, all we need to manage is however much we can ingest and digest. The bottleneck in our informational lives is absolutely not inventory management, it’s the bandwidth between our ears, which is the same is it’s always been.

Although this comment was made in the context of information overload online, I believe it is just as applicable to the increasingly amorphous capabilities of the tools and frameworks we use to power our sites and applications. A self-cannibalising cycle of being overloaded with the number of options presented to us so we create a new option, only to then overwhelm the next person that comes along ad infinitum (Relevant XKCD).

I’m fully aware of the irony in chastising the excessive number of frameworks out there only to have created my own personal one, however I feel there is a key distinction between the two. My personal framework was created as a learning project to help me not only manage this site going forward but also gain a deeper understanding of the tools I use on a daily basis. Because this site is built with just the 3 core languages of the Web (HTML, CSS, and JS) that knowledge is not only going to be long lasting but also easily transferable, regardless of what Web-based projects I work on next. In addition, the Bash scripts that help tie everything together are just Unix commands, programs that will be available almost anywhere I choose to work from.

When it comes to typical Web frameworks however, a considerable number are put out into the wild competing against each other claiming to be the definitive framework which only ends up muddying the matter. In addition, most require knowledge that is unique to that particular framework, making migration challenging. Of course, this is certainly not to say that all frameworks are bad and we should return to the Web of the 90’s; A more complex Web will always require more complex tools. However, for smaller simpler use-cases like a personal blog, plain HTML can still do the job just fine.

Working in a Computing-Science related job/field inherently requires the continual learning of new skills. However, surely that time is better spent learning new skills rather than progressing to where we already were before? Is it not a better option to expand your knowledge of your current toolkit rather than move and start afresh with a new one purely because it is newer?

I don’t have a particularly grand statement with this post other than that when building your site, don’t just leap straight to using the latest and greatest framework or technology. HTML never went away, it is still the fundamental backbone of the Web no matter how many layers we heap on top of it.