You're falling for the trap Vercel laid by having RSC co-opt the concept of SSR.
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.
Impressive to try and moralize this, but as someone born in "the large part of the world" you're aggrandizing for the typical project made in Next... I assure you that shipping a basic non-React project will be infinitely more appreciated than what RSC is enabling when combined with the style of frontend React encourages even if you do just render it down to a string.
> 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.
What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.
The framework is called React. As in Reacts. RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state.
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
The part about including "use client" by default is referring to component libraries. e.g. you don't want to import <ReactPagination/> and have it break because it uses useState. When writing your own components you can decide which need to be marked as client and which don't. I don't think NextJS is doing any harm by not magically including "use client" on your own files. I agree that it is confusing to be called "use client". Maybe "use interactive" would have been better, but regardless the "use client" directive is from React so I'm not sure why it's related to a complaint for NextJS.
I pointed out that the directive is for libraries, and stated the framework React is built on reactivity. The vast majority of the ecosystem is built on using state.
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.
Your comment sounded like you expected NextJS to add "use client" to everything to prevent it from breaking, I misunderstood, which is what my comment was referring to. I see that you mean they funded this effort that results in other libraries breaking. You may want to consider using more precise language instead of questioning others intelligence, it really isn't necessary.
I questioned if you understood the topic of my comment, and you replied that you misunderstood the topic. Jumping from that to somehow being an attack on your intelligence is ridiculous.
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"
Yeah: an pre-alpha toy project, and a blog post. Dan Abramov shipped a toy implementation too in a blog post right, I think you missed that?
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.
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.