Coming from the framework world with its wide streets, I learned that all the magic and convenience comes with a hidden price tag: every new version brought extra maintenance, dependency chains, and features I never asked for but had to carry.
My move to the web was a bumpy road — acronyms, frameworks, libraries everywhere. Go was not the obvious choice, since it’s rarely seen as a “frontend” tool. Go fix the HTML templates, CSS the beauty and JS for the interactivity. But I chose it anyway, despite the lack of convenience, and decided to document the journey.
Over time I saw two paths: one for traditional sites (multi‑page, SEO‑friendly), and one for more advanced apps(single‑page, dynamic). I chose to walk both.
I travel rather alone on this path, which is why I built a micro site to explain the journey: why there are few code buddies here, and why I enjoy walking off‑road despite the challenges.
Go as a frontend has proven faster and leaner for me than Drupal, WordPress or PHP. So why does it remain such a rare choice? Here is my 14 MB micro site hosted on a $1/month VPS:
I don’t think I’d say it is a rare choice. But most of the stuff I and many of my colleagues have built with Go is heavily data-driven, and in that arena SPAs really shine. So most of what I’m using Go for is building RESTful APIs that are consumed by SPAs/Mobile apps. And it’s a very good tool for that.
I do use templating in Go, but, there are many templating engines/tools out there. And in your case, I don’t see anything dynamic on that site so you might as well use a static site generator. You could use Hugo/Svelte and just statically generate all your content and then serve it up using whatever you want (you could, of course, still use Go to serve your content!).
If you’re talking serving static content, there are providers that will serve it for free. You could host your site on Github Pages for free, for example. Cloudflare pages/workers also has an incredibly generous free tier and excels at hosting HTML/CSS/JS content.
Correct. The dynamics will appear in the SPA part of the journey. I use a combination of Go SSR (adding dynamic data from Postgresql etc) into Go HTML Template and then let Javascript inject this pre rendered html.
But IMO static sites do not need Hugo or any other framework.
You should check out htmx if you haven’t! Similar approach to what you’re doing.
I mean - you get an entire community of developers with Hugo building plugins/themes. Easy templating. Local dev servers. Easy deployment to things like GitHub Pages. Etc. And all that is “free” versus rolling your own.
Everything that smells framework scares me. And HTMX is a framework to me. HTML with built in Javascript?
As soon as you add another layer upon the clean code, the extra layer is basically another language that you have to learn and find workarounds for. And a framework have a shorter lifetime than the language it is built upon. (as jQuery that is seldom used for new projects).
So as clean code as possible. That is why I like Go an Go HTML templates. Simple to make DRY and predictable. Both MPA and SPA.
So the aversion against frameworks is based on my experience. Magic is a pleasure until you have to maintain it for some decades.