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 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.
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.
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.
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.
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
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.
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'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 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.
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'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 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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
1. https://tanstack.com/blog/tanstack-start-1-0
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
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.
https://qip.dev/docs/router
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.
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/
https://astro.build/
[1] https://zine-ssg.io
edit: i mean have the ai write the generator, don't use it to actually generate pages...
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/