Well, here is that notorious first post. Basically playing with Hugo in an attempt to see how well it fits my workflow patterns. So far I am relatively happy with the tool .. though I feel like the Quick Start tutorial leaves a little to be desired. It is entirely possible that I am a little too technically minded and I just want the CliffsNotes version. [read: I am not the target audience .. which seems to be the norm for me for pretty much anything]
I spent quite a bit of time going through all of the Hugo themes and I was originally trying to decide between Beautiful Hugo and LoveIt, but alas the Loveit theme resulted in a number of errors when attempting to build the site, and the GitHub repo doesn’t look to be under very active development. Since I am not really in the mood to be adding yet-another-project to my seemingly endless bucket list of shiznittle it looks like Beautiful Hugo is the winner .. at least .. for now…
While experimenting with all of this I couldn’t help but notice that nearly nothing in Hugo seems to leverage Cache Busting out of the box. Again, it may be just me, but this feels like a horrible oversite in this day and age. Based on what I have been able to find on the net there is fundamentally no way to simply inject/apply/enforce cache busting within the configuration system such that it is automatically picked up by down-stream plugins/modules/themes. The end-result is that, if you want to follow modern best practices and guarantee that a browser is always showing the most recent version of the page (regardless of cache timers), then you are fundamentally stuck dealing with forking every module/theme you want to use and patch it up.
I was initially fairly disheartened with some of the solutions to Cache Busting w/in Hugo. Some of these articles seemed to understand the basic idea, but lacked some basic understandings as to how to do it such that they produced relatively complicated solutions.
For example:
-
Ukaih Smith had this article in which they set an Env Variable to a random number, and then included that random number into the file name every time they ran their build (which uses Make for some unknown reason). This is a little wild as it means caches are busted even if the file contents don’t change.
-
Ukaih Smith did realize the error of their ways and posted this article, though they never went back and corrected their first article to point at their new approach. While this approach is improved .. it is horribly over complicated for such a simple task… and it seemed to spawn other articles by others. E.g. https://www.ojisanseiuchi.com/2020/10/11/hugo-cache-busting/ Which is a great example of Cargo Cult programming and how it organically infects everything (a topic that is worthy of an unlimited number of rants IMHO).
I was deeply concerned that there wasn’t an easy solution to this problem w/in the scope of Hugo’s framework and was seriously pondering switching to an alternate static site generator such as Gatsby (where this problem is solved at the tool level). Luckily I managed to locate this article which lead me to Hugo’s asset management page (which for some reason I didn’t intuitively find when browsing the Hugo documentation). Suddenly there was hope of a future for me and Hugo together (in part because I am a fan of Go, and I am really not a fan of Node.js). Alas, this solution still implies that I need to patch any theme I choose to use if said theme is not already leveraging Cache Busting. Sooooo… I am still stuck with yet-another-project.
Unfortunately, the Beautiful Hugo theme only supports Google’s CSE Programmable Search .. soo .. a fork + patch later and I have added a local search based on a this gist from EddieWeb.
Lastly, while Beautiful Hugo supports StaticMan, the amount of work it would take to get StaticMan working with KeyBase would involve yet-another-project, and so I am looking at enabling Disqus.
Update (Thu 17 Feb 2022 11:06:32 PM UTC) Disqus enabled. Let’s see how much it annoys me.