When it comes to content-focused websites, which one is better: Hugo, Astro or NextJs?
First of all, I am not a developer and my knowledge on this subject is limited.
According to the information available in Astro’s documentation, Astro is best suited for content-focused websites while NextJs is more appropriate for more dynamic and complex websites.
I’ve been trying lots of the new ways to make a website. I had a quick look and try with astro.
Does the content include a lot of images for blog posts?
Images in page bundles much better than astro where images go in /src/ or /public/ (similar to assets and static folders in hugo)
Anything where I have to put all my images together is a hard fail on content organisation for myself as a photographer with image heavy posts and a professional as well as personal blogs.
Hugo’s image processing speed is excellent and it is a very easy setup with a render hook to get images exactly as you want them (figure / webp version / responsive / retina versions / set loading attribute). I even have them run a little bit of unsharpmask filter on the downsized images. All that functionality out of the box with no extra plugins to install.
But, with all that said . . .
Someone who puts in the time to get comfortable with Hugo templating will derive far more capability from Hugo out of the box than from just about any other SSG. Once they get a taste of what they can make Hugo do on its own — as opposed to having to beg a pile of Node.js packages to play nicely together — that’s a “Whoa” moment hard to forget. Indeed, one could choose Hugo simply for its built-in, rock-steady, astoundingly fast asset pipeline, Hugo Pipes; anyone who’s had to work with even the much-ballyhooed Vite (much less any other JS-based bundler/asset pipeline) will quickly see the advantage Hugo has in this specific regard.
. . . and I say all that as someone who’s used Hugo since 2018, Eleventy since 2019, and Astro (and, on occasion, Next.js) since 2021. I hope it’s helpful.
This will be a bit rambling and I apologize, but wanted to give you my POV. I write software docs for a living and I’m a bit biased towards Hugo for a number of reasons:
from a resourcing perspective, tech writing teams often don’t have access to or budget for talented JS developers that have the time to build + support a robust docs site using Next/Vue/Gatsby/etc, much less add new features over time. Marketing will not share its budget for site contract work, so you’re going to need approval from whatever department you’re sitting in – and it’s going to be a “no” unless you can do it all on your own.
JS sites require a lot more planning and dealing with props, states, etc. Getting from 0 to 1 is harder (I’ve tried several times – though i’m no JS expert). Most purchasable templates don’t meet large-scale content needs and lack features like nested menus, so you’re going to have to get competent enough in that framework to customize the components. This all makes for higher costs and more dependencies on an agency/contractor/some other team (see previous point as to why thats an issue).
Getting up and running on Hugo is, to me, a lot less complex because you can stick to traditional html, css, and small custom snippets of vanilla js to get quality of life features like dark mode, copy code, tabs, etc. I’ve built 3 startup docs sites with Hugo all by myself – and I’m hardly a great developer, I’m more of an aspiring developer. There’s so many great examples (Minikube, DataDog, etc) with open source repos where you can figure out how it’s done.
Golang templates are powerful; while there’s a learning curve, understanding Go is a good career move anyway. Every company I’ve worked for in the past 5 years have had primary product repos written in Go. The Hugo community is generally very helpful with any templating questions and often provide working templates for you. Also, your engineering department is often already very familiar with Go / Go templating logic, so getting some one-off help here is easy.
Hugo is so fast. When you’re drafting in markdown and looking at localhost, it just works. Even with 4000 pages, you’re looking at like <2 second loading. VS code + markdown plugins + hugo = <3 as a technical writer.
frontmatter. I love using it; with hugo, your article metadata is inside the same markdown file as your content — which makes a lot of sense to me. Most JS solutions manage those details in a separate json file (usually their menu files) which just feels…wrong? That means there’s more files to keep track of when you make major content changes like an IA overhaul.
I generally have found the Hugo template errors easier to troubleshoot than those from JS SSGs.
You don’t need NPM/Yarn/whatever – you certainly can add it, but I prefer to avoid it/the dependency hell it can bring.
a lot of JS solutions are trying to push writers into CMS WYSIWYGs. (like Tina.io). If you write docs for a living you’ll know why WYSIWYGs are terrible — I’ve wasted so much of my life fighting the auto-generated HTML of copy/pasted tables, links, etc. It’s such a time sink. Markdown is king.