Hacker News
points by pigbearpig 4 days ago | 0 comments
Respectfully, I don't understand this. They never needed Next.js for a static 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.

[–] dbbk 4 days ago
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.
[–] littlecranky67 4 days ago
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.

[–] onion2k 4 days ago
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
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.

[–] 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/...

[2] https://caniuse.com/picture

[–] 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.
[–] cpursley 4 days ago
Astro blows away next.js for static sites, especially blogs.
[–] littlecranky67 4 days ago
Care to elaborate and backup you wild claim with some facts?
[–] flexagoon 4 days ago
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?
[–] pier25 3 days ago
This is not even a remotely wild claim.
[–] flexagoon 4 days ago
The static export still keeps a large JS bundle which is mostly unnecessary
[–] vanderZwan 4 days ago
I think we should blame the elders for teaching people new to the trade wrong.

Because "heavyweight SPA for a static blog" isn't exactly a rare problem.

[–] vjvjvjvjghv 4 days ago
Young software devs don’t listen to their elders. They know better.
[–] austin-cheney 4 days ago
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.

[–] graemep 4 days ago
> My super large SPA loads in 150ms on localhost.

Which is great if people only use it from localhost.

[–] austin-cheney 4 days ago
Across a network it’s still only 300ms.
[–] graemep 3 days ago
Which means the difference between your APS and a static website is "loads reasonably fast" vs "loads instantly".
[–] austin-cheney 3 days ago
Sure, but that misses the point. My big SPA is faster without React and likely faster than a blog that appears to be static text generated from React. Yes, it would be much faster if it were just a few paragraphs of static text, but then it would not display any of the content that it is supposed to display, such as an a remote command shell interface or resource utilization graphs.
[–] graemep 3 days ago
That is reasonable but not clear to me.

The point being made further up the thread was that people are using SPAs for static text.

[–] dbbk 4 days ago
It wasn't the elders, it was Vercel itself which has a vested interest
[–] cbarrick 4 days ago
The OP is building a blogging platform, with an editor. It's not just a personal blog.

TBF, they could have explained that better in the post.

[–] phoghed 4 days ago
We’re also talking about a 5-point difference for the pagespeed score. It’s clear not many of these people read the post.
[–] mort96 4 days ago
The editor can be React, maybe even Next.js, but why does the generated page need to be?
[–] legulere 4 days ago
It's more like they realised they can also commute by bike or foot never realizing before that that was even an option
[–] z3t4 4 days ago
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.
[–] vjay15 4 days ago
exactly just use a ssg like zola/hugo and call it a day smh