(korindiehacker.bloffy.blog)
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.
Because "heavyweight SPA for a static blog" isn't exactly a rare problem.
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.
Keeping an unnecessary dependency for legacy reasons is never a good move. Be bold and delete things. Your software will be better for it.
But yes, another static site blog generator would also work.
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.
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.
Having said that, sure perhaps Astro would be lighter than Nextjs.
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
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 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’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.
Astro is also great (as others have noted) esp if you want to leverage the JS ecosystem at large.
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.
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.
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.
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.