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.
As a non-developer, I’m curious to know why someone would choose Astro over Hugo for a content-focused website (Hugo is easy to learn and use. Also written in Go ) and if someone has a preference for JavaScript, why choose Astro over NextJs (NextJs also have the option for creating Static Site)?
You cannot have the right answer to your question. You need to do your research and try on your own.
I recently read a post about SSG where @bwintx mentioned that he is picking between Eleventy and Hugo.
What was great was short summary:
If you’re really into JavaScript (or want to be), go with Eleventy. You’ll be much more comfortable there.
If you want maximum speed in development mode, go with the staggeringly fast Hugo. Be prepared to get comfortable with its wonky templating, however.
Read more here:
I tried a couple of SSGs before I settled with Hugo, as this framework nicely fits into my knowledge and area, where I can learn further about what I like, not necessarily what I need.
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.
If one prefers JavaScript and, I assume, simply refuses to get under Hugo’s “hood,” they’re better off with Eleventy than either Astro or Next.js. Eleventy is much simpler, more logical, and (IMHO) less brittle. Besides, everyone knows Next.js, as is true for most React-based platforms, tends to dump a ton of JavaScript client-side, which one’s visitors simply don’t need. Finally, Eleventy’s gradually adding plugins to enable capabilities, such as islands architecture and web components, for which Astro is justifiably popular.
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.
