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.
Next.js supports fully static export, so they should went with that.
Keeping an unnecessary dependency for legacy reasons is never a good move. Be bold and delete things. Your software will be better for it.
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.
My experience with Next.js is that because it mixes multiple paradigms, it makes using any single one of them more complicated and error prone.
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.
> 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.
The static export still keeps a large JS bundle which is mostly unnecessary
Astro blows away next.js for static sites, especially blogs.
Care to elaborate and backup you wild claim with some facts?
How is it a wild claim that an optimized plain html site is better for a static blog than a site with a huge redundant JS bundle?