After reading "Why you should write your own static site generator", I realized the build and deploy steps in my site is completely loaded with scripts (post-processing Hugo's output) and workarounds (such as using regex replaces for templating). And half the time I need to update something other than content I'll have to dig through the docs and forums.

Compare this with this one time I rolled my own SSG (for this single purpose), everything was centered around my build script and some shell tooling to move things around. I can make it output anyway I want, write templates in whatever format I like, place the content is whatever structure, and I just need to adapt my script for it. Well, granted this little project is much simpler than my site.

Is it really worth trying to adapt how I write to Hugo's framework, so it can generate an output closest to what I want, then use my own script to post-process the rest afterwards?

The main bottleneck right now that prevents me from rolling my own for my site (other than comparing "time pouring through Hugo docs" vs "time tweaking my new SSG") is the templating. This directly affect the tech stack I want to use. If I'm writing my own SSG now my best bet is probably Go + text/template + html/template to make my templates migration easier.

But at the end of the day, does having a smoother process of adding new features to my site actually make me produce better, more frequently updated content? Doubtful.

#ssg

GitHub - hedyhli/site: 🌐 my website and gemini capsule, statically generated by hugo (MIRROR of git.sr.ht/~hedy/site)

🌐 my website and gemini capsule, statically generated by hugo (MIRROR of git.sr.ht/~hedy/site) - hedyhli/site

^GitHub