points by onion2k 4 days ago | 0 comments
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.
[–] littlecranky67 4 days ago
[–] kypro 4 days ago
> 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.
[–] phoghed 4 days ago
As someone who’s never ran a blog for the past 25 years it’s surprising I never knew a blog was necessary until now
[–] nkmnz 3 days ago
As someone who's never ran for the past 25 years it's surprising I never knew.
[–] jakelazaroff 4 days ago
All those features might be good in some contexts, but they're also literally the reason the author's blog couldn't get 100s on Lighthouse.
[–] rhdunn 4 days ago
The picture element [1], [2] supports controlling which image is used via a media selector, allowing you to serve smaller images on smaller devices and on things like the viewport orientation.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[–] littlecranky67 3 days ago
Great and all such, but it doesn't do the actual work of resizing your one highres image to all those breakpoints - which is part of the build process in NextJS.
[–] CharlieDigital 4 days ago
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.
[–] christophilus 4 days ago
Image optimization is the only thing in that list I might care about, and every CDN I’ve ever used provides it out of the box.
But yes, another static site blog generator would also work.