I love Astro. It is so extensive to your liking and if you want to have complex interactive stuff at some point, you can just add a framework of your liking (react, vue, svelte, etc) and it will still work wonders. It doesn't abstract that much, and yet provides a nice UX and performance is top notch, which is why I love it so much. You can do from the most simplest website and blog on it, to the most complex content driven websites. I use it for so many different things, both hobbyist and professionally.
Astro is based on npm is it not? Given the state of that ecosystem and the rate at which new vulnerabilities are being discovered these days, I prefer to stay as far away from Node as I can.
I'm using tanstack+tailwind and Ai to write a few scripts for doing what static generators would do. Keep it simple, make it unique, bring back the weird
ai. like have them take your language of choice, your templating of choice, your architecture of choice etc and spit out something. they've seen enough that it can pretty much oneshot something relatively simple.
edit: i mean have the ai write the generator, don't use it to actually generate pages...
This is the right answer to the vague question of "best".
I started with an empty repo, wrote the first half of a README describing my decision-making process in choosing a static site generator, and conversed with an AI to finish the decision and set everything up.
I've done this after evaluating some "ready made please deploy me" solutions. Ended up picked Rust with Axum and it's crazy fast, code is super simple, but really powerful.
I use Hugo for one blog [1] and Zola for another [2], I think they're both pretty simple to use once you wrap your mind around how they structure things.
Astro is also great (as others have noted) esp if you want to leverage the JS ecosystem at large.
I'm going to push back against Astro because all the server island stuff is over-engineered for a blog, while in the meantime Astro is not designed for more complex sites so I'm not sure what it's purpose is really.
I would say that in the era of agentic coding you don't need any framework. Just a backend + router + markdown generator. I use Hono + Tanstack router for the first two. Tell any decent LLM to wire those up for you and you'll have a simple static site ready to go in an hour or two.
The server islands are completely optional tho, if you don’t want to use them, you don’t have to. For a simple blog you can just use collections, and plain HTML/CSS.
I’ve used Astro for more complex applications, and it’s perfectly suitable for that too.
Of course, if you’re building an SPA, then it’s probably not the best choice.
I'm on Hugo. It's simple, capable, well documented, LLMs understand it well, and I don't have to touch the JS ecosystem. My previous setup was with a Node based SSG and it broke on literally every update and had a hundred dependencies.
I moved away from Hugo because I was tired of it breaking backwards compatibility. I found that upgrading my Hugo version meant that old static website projects wouldn’t compile, and needed amendments. I keep an older Hugo binary around as I don’t have time for that now. Any new website projects are Astro, and I will aim to convert the older projects to Astro when time allows.
So many great options. I always opt for Web Origami though.
It is more like a dialect of JavaScript optimised for developing static sites than a static site generator in and of itself. It has lots of 'builtins' for things like RSS and converting Markdown to HTML. It is so wonderfully flexible and doesn't lock you into a specific site structure like others SSGs do.
Not sure about the best, but Zola is good enough for basic blogging needs. I liked the part that it was a single binary, so you don’t have to keep up with any breaking changes unless you want a new feature or a bug is bothering you.
Whatever you use, I feel it is tradition to have 3 odd blog posts about journey of building a SSG of your own since nothing else matched exactly what you needed and that’s it. Then you should forget that blog ever existed.
I made QIP Router where every part of rendering and making the HTTP response is customizable via WebAssembly. You often have a lot more control than a traditional static site generator that requires a particular plugin made — just make your own!
I like Zola. It is opinionated, but easy to pick up and get running in an hour or so. Not so great if you are working on a large website with lots of interconnected pages, but perfect for a blog, personal, or small company website.
I've been using Astro for my main blog and have been reasonably happy with it, but recently branched out for my Lab site to be just a simple static hub built with Vite/TypeScript/Tailwind, where each project subpage is bundled in its own slug folder so they can bring in additional dependencies.
I wrote not so basic CRUD application that uses HTML and vanilla javascript. I don't even minify the javascript. That website loads significantly faster than all the other websites I have made.
It is obvious, yet so many people don't understand it.
There is no secret ingredient, writing a website, or anything really, without a framework is not wildly more difficult than using a framework.
Save for a few cases where all you really want to do is covered by the default configuration, you generally don't end up writing a lot less code with a framework. Worst case, you end up spending most of your time working around the framework.
> you generally don't end up writing a lot less code with a framework
What? This is absolutely untrue for anything that isn't a trivial v1 prototype. Complex applications have a lot of boilerplate, which is unavoidable with the baggage of HTML and CSS.
There's a reason people are obsessed with web frameworks. Writing vanilla HTML/CSS/JS for large or complex apps is an enormous pain.
We use nextjs at work and I hate it. Why write each view once when you could write it twice?
I'm open to the idea that we're doing it wrong and that there's a correct and pleasant way to write nextjs, but I think with the tools available today, everyone should just profile and optimize their app so they don't need to render it serverside.
I recommend ditching Next.js in favor of Tanstack Start^1, an alternative metaframework that gives you more freedom, better DX, and better defaults. Stick w the best aspects of SPAs and introduce SSR selectively if and when it makes sense.
Didn't downvote, but my thought on your comment is: "More freedom" -> "More decision paralysis & anxiety", "New better framework X" -> "Latest hypecycle that will be require me to rewrite and relearn a framework that is deprecated in 18 months" etc.
I use Hugo published to Github Pages for my blog. I've never thought about performance (it's Fast Enough™ when I visit it), but I just checked and it's 100 on pagespeed. The magic of a static HTML blog is you don't have to think about performance. An entire category of problem just disappears.
Same we moved from Wordpress to Hugo when looking to update our company site page. Using AI to update the legacy Wordpress theme just wasn’t it. Had updated brand and style guide, Claude made short work of porting to Hugo and Google speed rankings were excellent even without cdn etc
I use Hugo as well. If any of your pages have larger media, look into Pipes to get images ladder srcsets built for you automatically. Very fancy. https://gohugo.io/hugo-pipes/introduction/
An “image ladder” is the same image resampled at several widths. It’s not a standard term; MDN calls the technique “resolution switching”.
A srcset lists those versions, and the browser picks the one that fits the current viewport and screen density. https://responsiveimages.org/ has details.
Hugo is great. I had Claude make the framework for my wifes site using Hugo, Netlify free tier, and Decap CMS. And I forced Claude to avoid any Javascript for the non CMS parts.
The vast majority of websites don't need Next.js or React. Those are only useful if you need dynamic and modular updates within the structure, or state management. We've defaulted to React because of the name recognition and simple intertia. It's not a good framework for websites in general.
I'm not convinced you need React/Next.js even in those cases. Web components work and LLMs are so capable of using them that I find there is increasingly little utility in big frameworks.
Difference is in the eventing model and complexity of state management in React's hooks based model vs vanilla's. WC is aligned with how JS callbacks naturally work. React is the only framework that points the callback to the component function.
I have a next.js SSG blog that easily hits 100 and loads ~instantly. I just don't think there's any point trying to have a rational discussion about next on hn.
I feel like these large frameworks will slowly die out with the advent of agents.
The big selling point of them was a fast, convenient dev experience with many features (most often unused) being built-in.
Now, those built-in features are becoming a security risk as more vulnerabilities are being found in their 1000s of lines of code, and the developer experience benefit is being nullified by agents whittling away the human involvement anyway.
Yeah, for now. I sense sentiment shifting against these frameworks lately, it might be reflected in their training in a few models time. Or, it’s possible I’m completely off the mark.
It's surely not difficult to tell the LLM to not use various tools and techniques? At least that works when I use one to create Bash scripts. Anything slightly complicated and the LLM drags in a dependency on Python when an AWK script would most likely be faster, shorter, and easier to maintain. So I just tell it 'Don't use Python',
It's pretty easy to get 100 on every lighthouse category even while using next. The scoring is based on how fast a page loads and what blocks its loading time. If you develop it with a bit of care, that is a non-issue. My funny agency website (https://www.pixlw.com/) is purely nextjs and it scores a 100 on Lighthouse as well because I kept working on it till it didn't.
Next.js supports fully static export, so they should have went with that.
I run a dynamic website on nextjs static export - landingpages and docs are fully static, login and user dashboard use REST calls to a non-nextjs backend. Blazing fast, no nodejs or SSR in production.
Wouldn't say unnecesarry. Nextjs static export has features such as dynamic chunking, eager-loading of chunks when you hover over a link, routing etc. With a plugin you get image optimization (different image quality levels and dimensions based on viewport size) etc.
But yes, another static site blog generator would also work.
> Wouldn't say unnecesarry. Nextjs static export has features such as dynamic chunking, eager-loading of chunks when you hover over a link, routing etc.
As someone who's ran a blog for 25 years it's surprising I never knew these things were necessary until now.
My super large SPA loads in 150ms on localhost. Yes, if it were just a static blog I might get it down to about 60ms.
The problem isn’t the size of the code. It’s the unnecessary framework complexity. Suggesting this to a corporate JavaScript developer, though, is like throwing acid on your own face as they whine about how impossible it is to do their jobs.
It's like taking a plane and adding 6 hours to the commute. But flying is more fun, at least in the short run. If you need to do it for years you would use more simple and stable tools.
Next.js is not a good fit for most applications. It honestly never has been. It has just been Vercel's relentless over-the-top marketing that has been trying to convince junior developers that it is.
Not to brag*, but that's what I've been doing since 2013 on my php blog [0]. It was actually the result of a hn warm hug of death. My CDN is just a separate webserver serving all static assets using nginx.
Both my css and js are dynamically minified and included in the html depending on which component is loaded on the page.
Am I missing something? Nextjs static export would have solved this I feel. And hosting it on Cloudflare Pages and put the CDN in front and you're done.
Having said that, sure perhaps Astro would be lighter than Nextjs.
aftbit | 9 hours ago
dotnetcarpenter | 9 hours ago
arecsu | 9 hours ago
stackghost | 8 hours ago
moi2388 | 6 hours ago
verdverm | 9 hours ago
slopinthebag | 9 hours ago
edit: i mean have the ai write the generator, don't use it to actually generate pages...
brlewis | 9 hours ago
I started with an empty repo, wrote the first half of a README describing my decision-making process in choosing a static site generator, and conversed with an AI to finish the decision and set everything up.
https://writing.brlewis.com/posts/2026/blog-based-on-git/
tiborsaas | an hour ago
jazzypants | 9 hours ago
https://astro.build/
abound | 9 hours ago
Astro is also great (as others have noted) esp if you want to leverage the JS ecosystem at large.
[1] https://frominsidethebox.com
[2] https://yakshed.com
esperent | 9 hours ago
I would say that in the era of agentic coding you don't need any framework. Just a backend + router + markdown generator. I use Hono + Tanstack router for the first two. Tell any decent LLM to wire those up for you and you'll have a simple static site ready to go in an hour or two.
chrisweekly | 8 hours ago
woutr_be | 7 hours ago
I’ve used Astro for more complex applications, and it’s perfectly suitable for that too.
Of course, if you’re building an SPA, then it’s probably not the best choice.
danpalmer | 9 hours ago
hn_throw2025 | 3 hours ago
hutusi | 9 hours ago
OuterVale | 9 hours ago
It is more like a dialect of JavaScript optimised for developing static sites than a static site generator in and of itself. It has lots of 'builtins' for things like RSS and converting Markdown to HTML. It is so wonderfully flexible and doesn't lock you into a specific site structure like others SSGs do.
https://weborigami.org/
7777777phil | 9 hours ago
ErenayDev | 9 hours ago
[1] https://zine-ssg.io
analog_daddy | 9 hours ago
Whatever you use, I feel it is tradition to have 3 odd blog posts about journey of building a SSG of your own since nothing else matched exactly what you needed and that’s it. Then you should forget that blog ever existed.
ovrnightr | 7 hours ago
burntcaramel | 8 hours ago
https://qip.dev/docs/router
jddecker | 8 hours ago
vunderba | 7 hours ago
4pkjai | 9 hours ago
smt88 | 8 hours ago
The question is how to get a good and efficient dev experience while also preserving that level of speed.
AI has now made that question mostly irrelevant, since it can generate and rapidly edit vanilla webpages without a framework to make the DX better.
NohatCoder | 2 hours ago
There is no secret ingredient, writing a website, or anything really, without a framework is not wildly more difficult than using a framework.
Save for a few cases where all you really want to do is covered by the default configuration, you generally don't end up writing a lot less code with a framework. Worst case, you end up spending most of your time working around the framework.
smt88 | an hour ago
What? This is absolutely untrue for anything that isn't a trivial v1 prototype. Complex applications have a lot of boilerplate, which is unavoidable with the baggage of HTML and CSS.
There's a reason people are obsessed with web frameworks. Writing vanilla HTML/CSS/JS for large or complex apps is an enormous pain.
post-it | 9 hours ago
I'm open to the idea that we're doing it wrong and that there's a correct and pleasant way to write nextjs, but I think with the tools available today, everyone should just profile and optimize their app so they don't need to render it serverside.
chrisweekly | 8 hours ago
1. https://tanstack.com/blog/tanstack-start-1-0
chrisweekly | 7 hours ago
littlecranky67 | 5 hours ago
cpursley | 5 hours ago
agos | 5 hours ago
cpursley | an hour ago
tengbretson | 8 hours ago
LoganDark | 9 hours ago
dzink | 9 hours ago
benmccann | 9 hours ago
SwellJoe | 8 hours ago
ct520 | 8 hours ago
mceachen | 8 hours ago
stackghost | 8 hours ago
mceachen | 8 hours ago
A srcset lists those versions, and the browser picks the one that fits the current viewport and screen density. https://responsiveimages.org/ has details.
For an example, view the source of https://photostructure.com/tags/. All the header art looks like this:
<picture><source type="image/webp" srcset="/img/2026/05/desk-2000w_hu_f9b8e901c6d3512c.webp 400w, /img/2026/05/desk-2000w_hu_4e2d65cccd03c969.webp 800w, /img/2026/05/desk-2000w_hu_11f3bf6c90dbf78d.webp 1200w, /img/2026/05/desk-2000w_hu_8c1a7d0a013e4ee2.webp 1600w, /img/2026/05/desk-2000w_hu_4cebe999e55b5486.webp 2000w" sizes="100vw"><source type="image/jpeg" srcset="/img/2026/05/desk-2000w_hu_cf5671a2e3bdd0cc.jpg 400w, /img/2026/05/desk-2000w_hu_2906e4ba7cda040.jpg 800w, /img/2026/05/desk-2000w_hu_f59ef0388799d4d2.jpg 1200w, /img/2026/05/desk-2000w_hu_e183d28df837e14a.jpg 1600w, /img/2026/05/desk-2000w_hu_ea9c422963c8e0e1.jpg 2000w" sizes="100vw"><img src="/img/2026/05/desk-2000w_hu_f59ef0388799d4d2.jpg" width="1200" height="600" alt="About" class="w-100 header-image" loading="eager"></picture>
That’s generated by https://gist.github.com/mceachen/d5915e46d1294489698e155eb11..., which uses Hugo’s resources.Get and .Resize.
nullify88 | 7 hours ago
ogou | 8 hours ago
tempay | 7 hours ago
agos | 5 hours ago
CharlieDigital | 2 hours ago
fergie | 4 hours ago
sampli | 8 hours ago
tkzed49 | 5 hours ago
reassess_blind | 8 hours ago
The big selling point of them was a fast, convenient dev experience with many features (most often unused) being built-in.
Now, those built-in features are becoming a security risk as more vulnerabilities are being found in their 1000s of lines of code, and the developer experience benefit is being nullified by agents whittling away the human involvement anyway.
cpursley | 7 hours ago
reassess_blind | 6 hours ago
egeozcan | 6 hours ago
ninalanyon | an hour ago
altmanaltman | 8 hours ago
pigbearpig | 7 hours ago
This is like writing a post about how I didn't need a Ferrari to commute to work and I saved money by taking the bus.
littlecranky67 | 6 hours ago
I run a dynamic website on nextjs static export - landingpages and docs are fully static, login and user dashboard use REST calls to a non-nextjs backend. Blazing fast, no nodejs or SSR in production.
onion2k | 5 hours ago
Keeping an unnecessary dependency for legacy reasons is never a good move. Be bold and delete things. Your software will be better for it.
littlecranky67 | 5 hours ago
But yes, another static site blog generator would also work.
kypro | 3 hours ago
As someone who's ran a blog for 25 years it's surprising I never knew these things were necessary until now.
CharlieDigital | 3 hours ago
Not just as the dev delivering the solution, but also library and package authors.
Ran into lots of issues around Next 12, Next 13 was very buggy, moved to Astro and never looked back.
jakelazaroff | 48 minutes ago
christophilus | 38 minutes ago
cpursley | 5 hours ago
littlecranky67 | 5 hours ago
flexagoon | 3 hours ago
flexagoon | 3 hours ago
vanderZwan | 5 hours ago
Because "heavyweight SPA for a static blog" isn't exactly a rare problem.
dbbk | 2 hours ago
austin-cheney | 2 hours ago
The problem isn’t the size of the code. It’s the unnecessary framework complexity. Suggesting this to a corporate JavaScript developer, though, is like throwing acid on your own face as they whine about how impossible it is to do their jobs.
graemep | 56 minutes ago
Which is great if people only use it from localhost.
vjvjvjvjghv | an hour ago
legulere | 3 hours ago
z3t4 | 28 minutes ago
vjay15 | 3 hours ago
dbbk | 2 hours ago
cbarrick | 15 minutes ago
TBF, they could have explained that better in the post.
Exoristos | 7 hours ago
s1n_ | 6 hours ago
darkwater | 3 hours ago
firefoxd | 7 hours ago
Both my css and js are dynamically minified and included in the html depending on which component is loaded on the page.
[0]: https://idiallo.com/blog/handling-1-million-web-request
* I am bragging
nickphx | 5 hours ago
pampas | 4 hours ago
Hamuko | 54 minutes ago
christophilus | 33 minutes ago
prtmnth | 4 hours ago
Having said that, sure perhaps Astro would be lighter than Nextjs.
dev_l1x_be | 4 hours ago
ceving | 3 hours ago
ninalanyon | an hour ago
graemep | 57 minutes ago
Then chooses an approach that looks like a lot more work than setting up Hugo.
ActionHank | 36 minutes ago