[MPiccinato]

I will have to give this article a more full read rather than just a skim, but...

I am left with such confusion as to how React/Next arrived at this solution. `useEffect` didn't run on the server when doing SSR, great, easy enough to understand. Now several common hooks don't run on the server because they are considered interactive? And it isn't that they won't run, their initial pass in most cases doesn't do anything, it is that Next now yells at you for having a `useState` hook in a "Server Component".

I would like to write a component, not have to think about where it is running in most cases, and go on with my day. I mostly use React for large SPAs and have adopted Next for doing SSR on the few pages that I needed it for (SEO, etc).

[BoorishBears]

Vercel is how, and Next.js is like a trojan horse at this point.

As much as the React team tries to push back on it, Vercel marketing has become synonymous with React's direction.

Most people do not need a single thing that Vercel/Next.js thought leaders are trying to shove down their throats.

Unless you're competing with Facebook for SEO rankings (good luck) the 1KB you saved by not shipping an un-interactive component down the wire is nothing.

They're actively pushing a set of best practices that align with their hosting model and building a moat around said hosting

—

Also despite the intentionally confusing wording, Server Side Rendering does work with Client Components!

There are literally *hundreds* of posts where people are unaware of that because the directive chosen by the React team was "use client"... which naturally leads people to believe "use client" will opt out of SSR.

—

To me that choice, and not allowing a project wide disabling of it, were the last straw that took it from innocent misalignment to intentional.

By having the thought leaders sell these heavily server involved features they've create a situation where technically you can move your Next.JS project anywhere... there's just a scary (for those who don't know better) laundry list of things that won't work unless a given provider goes out of their way to enable it.

They get to play both sides: Next.JS works anywhere (as long as you ignore a bunch if features that we sell as being very important to making a good site)

[danabramov]

Do you have terms that you prefer (to Server/Client split)? I agree they're confusing but I haven't seen any proposal that would address the issues with them without introducing other issues.

I've tried to explain our current terminology here: https://github.com/reactwg/server-components/discussions/4

[silenthoughts]

That is also my issue with NextJS -- it is utterly confusing trying to figure out what they mean when they say "server" or "client". Are they talking about the backend server and what client do they mean? These words become extremely confusing when you might be developing a full stack feature or service that has multiple clients, a backend API, etc...

[danabramov]

While this may not be satisfying, I tried to write a response to a similar question here: https://github.com/reactwg/server-components/discussions/4

[uryga]

> I would like to write a component, not have to think about where it is running in most cases

you can keep doing this, just put "use client" in the file, Next will SSR them just like it used to. (SSR is an "emulated client" in this model. admittedly, the naming is a bit confusing)

but for some things, you want a guarantee that it only runs on the server, and then you can use server components :) i believe this is also why useState & friends are disallowed there -- they fundamentally don't make sense for stuff that'll only ever run server-side.