I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14, of all things, do you find people saying that actually SPAs are great and SSR is a regression!
People are complaining about server components and the machinery to enable them: but those are actually unrelated to SSR.
Client components are rendered on the server.
-
SSR was the sane middleground that worked since Next.js 1.0: You generated some content, and the frontend had all the Javascript and used that content to give a snappier SEO friendly experience.
Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
For people with medium and high end devices, SPAs are mostly fine. For those with low end devices (which is a large part of the world), SPAs sometimes don't work well and this is true of many UI frameworks.
Real human beings benefit with you ship less code. And, if people are paying for data, which a lot of people still do, this matters.
> Real human beings benefit with you ship less code.
Real humans beings benefit from reliable and well-made applications more.
The difference between an good engineer and a truly excellent engineer is understanding how "worse" technical choices can result in a better user experience.
Junior engineers obsess over low level metrics like how many lines of code they right, but for some reason people graduate to obsessing over how many bytes of JS they shipped and don't think for a second:
- "how much of a surface area did I just open up for bugs in my chase?"
- "how much productivity spent catching up on this new paradigm would have been better spent making what my users want and need rather than tinkering with implementation details?"
- "how is adding this convoluted multifaceted multistep approach with an unstable technology going to affect the stability of my application?"
- "how much harder did I just make it to solve the bugs I do know about due to indirection?"
You're shipping less code down the pipe but you're dragging in insane amounts more code at every step of the way from compilation to the server runtime to enable it: the net result is a buggier, more complicated, less reliable application.
Of course, when you make money off people not thinking about this stuff, you don't encourage discussion of it.
It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name, does the literal basic tenant of React work again.
The RFC literally states libraries should embed this directive to not break builds: that means Vercel managed to fund an effort that breaks the underlying value proposition of a decade old framework by default
Absolute insanity.
Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build.
_
And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing any harm by not magically including "use client" on your own files"
Vercel drove RSC home for Next.js. Shopify tried it (because eCommerce) the effort petered out, and then Next.js, needing a bullet in the chamber against Remix and Hydrogen went and dragged a half-baked concept antithetical to the underlying technology over the finish line.
Next.js is still the only actual implementation of RSC: Remix tried it and wrote it off for very obvious reasons... since Vercel/Next.js got to write the framework side and the implementation, there are a massive number of gaps in the standard.
Also not sure how much more precise I can be in saying "they funded this effort" than my original comment which says "Vercel managed to fund an effort"
Here's one https://github.com/dai-shi/waku. Also, Redwood is "all in on Server Components" https://tom.preston-werner.com/2023/05/30/redwoods-next-epoc....
When I said actual I meant it. RSC is a Next.js feature baked into React.
PS: I'm not the target market for Vercel, Mr. Robinson. I think you can skip the damage control for my comments: I don't have your reach so maybe just pretend it's an old man yelling (very truthful things) at the clouds, it can't actually hurt your PR machine.
SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.
Literally every other HN thread I see has at least handful of people pushing Astro.
I'm not disagreeing with this actually - but I've also never been a massive fan on SSR for React. In addition - NextJS goes further in inhibiting React functionality - for instance: useLayoutEffect doesn't work at all.
With everything else being DIY integration, and lesser tooling.
EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.