I’ve built my first website with GoHugo and absolutely loved the experience. Working with Hugo has been pure joy!
Before this, I mostly worked with various JavaScript frameworks, where you usually have to build everything from scratch and design your own architecture by yourself. With Hugo, I really enjoy that the necessary decisions have already been made for you, it feels structured and very clean.
Layouts, pages, built-in functions and methods - everything is provided out of the box. Need to show the last updated or published date? Just call a built-in function in one line - done! Pagination, categories, tags - everything just works out of the box.
The only thing I’m missing is server-side rendering (SSR). It’s honestly a bit sad that I have to look for other tools because I enjoyed working with Hugo so much.
So here’s my question:
Since Hugo is built with Go, are there any Go-based frameworks similar in concept to Hugo, but that support SSR?
Or maybe other frameworks (not necessarily in Go) that are conceptually close to the Hugo approach?
For a project that was mostly static but needed some parts to be dynamic I would use Hugo plus HTMX with your preferred backend. For me the backend would be Django or maybe Flask.
I use HTMX for a large Django project and it’s a joy to work with.
I heard great things about htmx … I also enjoy working with AlpineJS, works great with Hugo. But none of those support SSR as far as I know.
But … why do you need SSR? Is this mainly to make Google PageSpeed happy? You’re adding lots of complexity for a few milliseconds shaved off the initial page render.
why do you need SSR? Is this mainly to make Google PageSpeed happy
As far as I know, an SSG site will be faster than SSR site.
I’m planning to build an API-based website, where all the data across the site should be updated very often. Technically, I can easily build a static site with Hugo using GetRemote function to extract data from the API.
But the data is updated very often. So on an SSR website, I can build a static site once per day through a cron job (if I want to combine SSG+SSR modes, or just make it SSR all the time), and then just extract data on the server side on each request per user. Technically, I can render API data using JavaScript, but it’s not good decision for accesability.
But the main concern is the second feature - I have filters and pagination based on my API. And it’s impossible to filter dynamic data with a static site. I need a server to do that.
Do you plan to implement SSR mode for GoHugo? Make it a full-stack framework, please.
Setup: Tailwind CSS, code minification, also built simple image.html shortcode which can optimize even dynamically imported images, so easy and feature rich, I’m really shocked, how easy you can do things with GoHugo compared to the frameworks I’ve worked before.
What I was asking, is why should hugo have anything to do with server-side anything ? From the little I know about scripting, htmx or similar techs, are just a bunch of javascript libraries taking charge of answering http requests or alter behavior on the client side. Hugo builds site, it doesn’t run a full-featured web server.
SSR in this context means server side rendering of dynamic content (content produced by JavaScript) so that the initial page load is HTML only – and then shifted out with client side rendered content; this is called hydration. Here’s a pretty good explanation: Understanding Hydration in React applications(SSR) | Saeloun Blog
So, if you have a (typical) Hugo site where 99+% of it is static HTML, SSR is not needed.
I can give a real-life example. I work at a betting company (https://fonbet.com/), and the data from the API updates very frequently — things can change within minutes (odds, data, etc.). They definitely don’t use Hugo (unfortunately, I guess). They have their own rendering system that constantly crawls the site, removes finished events, adds new ones, builds some things dynamically and some statically. They even have a separate renderer for search and another one for users. This creates tons of problems both for indexing and for handling all those URLs.
It’s a real-world product, what can I say — and compared to that, just using Hugo + Tailwind is like heavenly manna, where you control every page and know exactly what the user, the search bot, or any other bot will receive 99.9% of the time.
Now that I’ve read more about SSR, hypermedia etc and… came to the same naive conclusion: If you need to create pages dynamically or respond to http requests with json, a STATIC site generator has nothing to do with it. It is a server thing. They’re not opposite but completely orthogonal need.
Only your web server is responsible for dealing with http requests. If the constructed part of your content is too big you may as produce everything on the fly using the templating language of tools like django, whose langage looks like golang.
Not Go based, but I used Sveltekit for my webapp Ticket Auction Manager 3 with good results. I’ve seen people make anything from Blogs to eCommerce sites with it on Youtube.
To bring in SSR rendered data, for each page route you’d have to create a +page.server.js file, export a function (can be async) titled “load” and then bring in the object it returns by destructuring data from the $props() rune in the +page.svelte file. So it’d be something like this:
const {data} = $props();
If you set it up with the Node adapter, you can run it on any computer that has node or even inside of a Docker/Podman container.
If you’re doing this just for the performance, I wouldn’t really recommend SSR, especially for shear volume. As it will slow down the server a lot more during high traffic volumes (as the server will have to think more instead of just handing files to the client).
If you get low speed marks (90+ is actually good) on a SSG site, then it’s likely a bandwidth issue (consider a VPS plan with higher link speeds) or you have media that’s obnoxiously big. Or a blocking load function in your JS code (if you have any).
I’d only push for SSR if you’re doing something that requires dynamic content.
