Hugo: Or, There and Back Again

There has been quite a lot of reaction to Web 3.0 of late. For those who don't keep up with the tech that underpins the systems and services they use, Web 3.0 can loosely be described as a new iteration of the World Wide Web based on blockchain. If that seems as unintelligible as me simply saying Web 3.0, that is probably because it is. But allow me to try and unfold the scene a little by beginning at the beginning.

Back at the dawn of the World Wide Web, or Web 1.0 as it has since been named, sites were static. That is to say someone would write a bit of code, host it on a server and the user's web browser would display the page content once called. Interaction — either between users or systems — was largely unknown thus the term 'static', because the page would remain unchanged until the content creator updated the code.

Content was served from a [filesystem](https://en.wikipedia.org/wiki/File_system “File system”) rather than a relational database management system ([RDBMS](https://en.wikipedia.org/wiki/RDBMS “RDBMS”)), the infamous [<blink>](https://en.wikipedia.org/wiki/Blink_element “Blink element”) and [<marquee>](https://en.wikipedia.org/wiki/Marquee_tag “Marquee tag”) tags abounded, and interaction between users consisted mainly of [mailto](https://en.wikipedia.org/wiki/Mailto) forms — where a user would need to open their email client to message the content creator. The notion of communication with other visitors to the site was ostensibly unknown.

But what Web 1.0 lacked in interaction and media complexity, it more than made up for in elegant minimalism. A trait which is important to remember as we will revisit it in a few paragraphs.

Web 2.0 changed all of this. As [Darcy DiNucci](https://en.wikipedia.org/wiki/Darcy_DiNucci “Darcy DiNucci”), an [information architecture](https://en.wikipedia.org/wiki/Information_architecture “Information architecture”) consultant, observed in her January 1999 article [Fragmented Future](https://web.archive.org/web/20111110143942/http://darcyd.com/fragmented_future.pdf):

The Web we know now, which loads into a [browser window](https://en.wikipedia.org/wiki/Web_browser “Web browser”) in essentially static screenfuls, is only an embryo of the Web to come. The first glimmerings of Web 2.0 are beginning to appear, and we are just starting to see how that embryo might develop. The Web will be understood not as screenfuls of text and graphics but as a transport mechanism, the ether through which interactivity happens.

Web 2.0 brought greater opportunities for interaction through the dynamic serving of content. This enabled the rise of social media sites, [wikis](https://en.wikipedia.org/wiki/Wiki “Wiki”), video and image sharing services, and for blog functionality to go beyond the guest book or mailto link and deliver truly interactive experiences that responded to visitor interactions.

While this undeniably introduced bloat to sites — creators packing pages with dynamic content because they could, not because they should — it also introduced the notion of centralising content onto platforms, away from self-managed servers. A situation which leaves even the largest services open to being [completely offline](https://www.theverge.com/2021/10/4/22709260/what-is-bgp-border-gateway-protocol-explainer-internet-facebook-outage).

It also raised the issue of gate-keepers, because whoever controls the service can determine [who will and who won't have a voice](https://robert.winter.ink/parliamentary-privilege/). This in turn has surfaced ever more urgent calls for making internet services and sites truly decentralised.

## Forward To The Past

While the blockchain offers new opportunities to reset the centralising tendency of Web 2.0, a growing band of intrepid content creators believe the approach of back to the past, and the glory days of static sites, offers a far better path to online nirvana than the much touted blockchain.

I won't go into the interminable details of Web 3.0, that is [being unpicked](https://moxie.org/2022/01/07/web3-first-impressions.html) by greater tech luminaries than me. I only raise it by way of local colour for the case already surfaced during Web 2.0 — that a better way to serve site content needs to be found.

With some [technologists ditching CMS](https://kevq.uk/goodbye-wordpress-switched-to-jekyll/) for the world of static site generators, I have noticed an ever growing chorus of people extolling their move away from a CMS like WordPress or underlining long standing credentials in their choice of a static site.

My [source code](https://en.wikipedia.org/wiki/Source_code) awake and aware readers will have noticed that I too walked the static past over the Christmas break. In between gorging myself on turkey, port, and truffle chocolates, I found occasion to spin up a GitHub account and learnt how to deploy [Hugo](https://gohugo.io/). Once my inevitable rage about how technology is documented had abated — why is it that every user guide requires a swathe of assumed knowledge — and my long suffering wife had wondered why I take on projects like this every holiday, I had migrated [robert.winter.ink](https://robert.winter.ink/) to its new [Netlify](https://www.netlify.com/) home.

There was much I loved about being on Hugo. The nostalgia involved in meticulously agonising over every html tag and css class, the simplicity and intelligibility of the source code, the joy of [writing in markdown](https://robert.winter.ink/zettelkasten-method/) and having my [Git workflow](https://robert.winter.ink/zettelkasten-method/) push this straight to my site. But for all the joy, there was an underlying tension: that I was back in the loop of spending more time maintaining code than producing content. Plus there were bugs.

I like to call them bugs, because a technologist of my unimpeachable genius couldn't possibly make a mistake with my code. Thus it must be a bug, or perhaps new 'feature', in the solution.

What also troubled me about the experience was the unshakeable feeling that I was being sucked into a game of [Top Trumps](https://en.wikipedia.org/wiki/Top_Trumps), where site operators compete with each other to determine who has the [least bytes](https://512kb.club/), who has a perfect [GTmetrix](https://gtmetrix.com/) score, or who can live [A Reality Where CSS and JavaScript Don't Exist](https://tdarb.org/css-js-mistake/). Perhaps what was most bizarre, though I was certainly a victim of this, was the focus — nay obsession — with which static site generator compiles a site fastest.

For those unfamiliar with the static site process, to publish your content you need to **build** your site before deploying it to a server. This differs from a CMS like WordPress where your site is always **deployed** and you add content to the extant deployment as you go.

Given builds take a matter of seconds, and given few visitors have any clue you had a **build** process to go through for them to see your content, this is perhaps one of the more bizarre Top Trumps moments in the static site world. For those for whom any of the last few paragraphs made any sense, and thus who likely care, my Hugo site stats were:

| EN

-—————————+———

Pages | 653

Paginator pages | 58

Non-page files | 111

Static files | 0

Processed images | 0

Aliases | 250

Sitemaps | 1

Cleaned | 0

Built in 735 ms

I should declare an interest, or provide an aide-mémoire for those who already knew, that this quest for minimalism and speed isn't something to which I am opposed. I have mused on the benefits of a [site with less byte](https://robert.winter.ink/site-with-less-byte/) and continue to support a [cleaner web](https://robert.winter.ink/sustainable-web-bibliography/). But I'm not running a site which lives or dies by its speed. As the preceding 1,105 words have alluded, I am a writer who prefers long form to five words or less click-bait. Thus the readership I enjoy is going to be attracted or repelled by the content, not because I have a low LCP (largest content element). For those who have made it this far and are actually wondering about my LCP, since moving back to WordPress on **shared hosting** my LCP is now 2.9s — up from 556ms on a Netlify powered Hugo site. Yes, the pragmatists among you will have observed: “blink, and you'll miss the site load time difference.”

For those contemplating their own publishing platform, this shouldn't be seen as a sign that WordPress is inherently unable to be light and responsive. [Susty WP](https://sustywp.com/) is a legend in the community delivering a site in under 7KB with an LCP of 852ms.

Holiday over and time once again being at a premium, I mused on my latest quest for minimalism. In doing so I realised that I was creating as many problems as I was solving. A classic in this genre of new problems was the endless hoops I had to jump through to solve for an RSS feed and to get feature images displaying on social media — I never solved the latter problem. To that end, I have bounced off the nadir of Soviet era minimalism and returned to the zenith of decadent baroque extravagance. That is to say, I'm back on WordPress.

I have been through this exploration of platform before, tinkering with [write.as](https://robert.winter.ink/how-i-publish-2-0/) and [Ghost](https://robert.winter.ink/how-i-publish-3-0/) before returning to my [old faithful](https://robert.winter.ink/how-i-publish-4-0/). This is an important part of the scientific process, testing and retesting. It is also an inevitable side effect of being a [platform junkie](https://robert.winter.ink/confessions-of-a-platform-junkie/) and from adopting the Churchillian adage:

To improve is to change; to be perfect is to change often. — [Winston S. Churchill](https://en.wikipedia.org/wiki/Winston_Churchill)

This is why I will go on one of these little escapades again, in between continuing to hone my WordPress installation.

Goodnight and good luck.

-—

[Social Media and Technology](https://commons.wikimedia.org/wiki/File:Social_Media_and_Technology.jpg) by [Animated Heaven](Escapism of Eternity) is licensed under [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/).