6 ms·

> As I write this, there's only one way to start using React Server Components, and that's with Next.js 13.4+ I don't understand how this is acceptable to the

> As I write this, there's only one way to start using React Server Components, and that's with Next.js 13.4+ I don't understand how this is acceptable to the React user community, that only Vercel gets to be in this privileged position. Why did they not include other companies, or the users themselves, in the discussion and development of this feature. > Since Server Components are a new React feature, third-party packages and providers in the ecosystem are just beginning to add the "use client" directive to components that use client-only features like useState, useEffect, and createContext. > Today, many components from npm packages that use client-only features do not yet have the directive. These third-party components will work as expected within Client Components since they have the "use client" directive, but they won't work within Server Components. The arrogance of expecting all third-party packages, React-related or not, to buy into the "use client" directive. A humbler approach would have been a "use server" directive to opt-in to this behavior, instead of expecting the entire rest of the ecosystem to adapt to it.

paulddraper 3y ago
Facebook open source has been quite good (React, GraphQL, Buck, PyTorch). This is...weird. How did Vercel manage that?
- marksomnian 3y ago
  Dan Abramov (React core team, formerly of Meta) talks about this in a Twitter thread: https://twitter.com/dan_abramov/status/1654688751342301184 https://twitter.com/dan_abramov/status/1654688751342301184 In short, it's because Vercel invested engineer-years into piloting RSCs as part of a production framework and making Next the guinea pig. Next wasn't actually the first framework to try RSCs - Hydrogen (Shopify) and Gatsby both tried early versions of it and provided feedback, but Next is the first to implement it to the point that it can be considered stable. The long-term goal is that RSCs aren't a Next-only concept - for example the Remix team said that they wouldn't implement them until they became more stable (https://twitter.com/ryanflorence/status/1678416472010260480 https://twitter.com/ryanflorence/status/1678416472010260480), but are working on it now (https://twitter.com/ryanflorence/status/1697253955376722092 https://twitter.com/ryanflorence/status/1697253955376722092). But the React team has always historically favoured trying new features in production to iterate on the API (this happened a lot internally at Meta), and this was an opportunity to do that.
  - tshaddox 3y ago
    Also worth noting that after experimenting with RSCs in Hydrogen, Shopify acquired Remix and is now building Hydrogen using Remix.
    - danabramov 3y ago
      Also worth noting that Remix is working on RSC support right now.
foota 3y ago
Reading further, use client is viral, and propagates to children components.
- danabramov 3y ago
  "use client" is more of a bundler feature. It doesn't propagate to components per se, it affects the import tree. You can think of "use client" as a directive that says: the entire module graph below gets shipped to the client bundle.
deleted 3y ago
[deleted]
adamesque 3y ago
The reason Vercel was selected for this privilege is pretty simple, to my understanding: they volunteered and committed engineering resources to partner with the React team to work through a pretty major and experimental new API with a lot of expected breaking changes. Child of a sibling comment has more details: https://news.ycombinator.com/item?id=37408918 https://news.ycombinator.com/item?id=37408918
- qudat 3y ago
  Further, some react devs are now working full time for vercel. Money is to be made on both sides which is why this relationship exists.
  - uryga 3y ago
    how exactly is there "money to be made" here for the React team?
TheCoelacanth 3y ago
Third-party packages don't need any directives unless they specifically want to put a client/server boundary in their component. The directive marks where the transition from server to client happens. If you aren't already starting in a server component, then you don't need to do anything to use client features.
- BoorishBears 3y ago
  > If you aren't already starting in a server component, then you don't need to do anything to use client features. This is a deceptive reply since the only RSC implementation in existence starts from a server component. That means that having React State, a basic building block of React that's leveraged massively across the ecosystem, is broken by default until the user adds a "use client" directive. They're 100% right that "use server" should have been the directive, and more specifically it should have been something like "use non-interactive". Server vs Client is already widely understood to be tied to SSR in a completely orthogonal manner. RSC has a much narrower value proposition that shouldn't have gotten muddied by all this.
  - danabramov 3y ago
    The design you're suggesting doesn't work because it would cause server/client waterfalls everywhere, which goes against the entire purpose of the architecture. The data flows in one direction: from the server to the client. It's just physics — your server is where the data is. You're trying to move it to the client. So the code that needs to run first is the server code. This is why the data flow starts at the server. You can't fix this by changing how opting in works, or some other API design workaround. What you're fighting with is the arrow of time. As for the terminology, I agree it is confusing, but I have not seen a better suggestion yet. I shared our reasoning here (https://github.com/reactwg/server-components/discussions/4 https://github.com/reactwg/server-components/discussions/4), hope it's helpful.
    - BoorishBears 3y ago
      There's nothing about it "that doesn't work": it simply isn't as effective at getting people moving to the mental model you're prescribing. People would have mostly trucked as they have. Except people not wanting to do that mental shift was largely why they chose Next.js over a framework like Remix. Choosing a default that breaks things (forcing npm packages to label their components...) was way too heavy handed considering the tenuous nature of RSC as a whole with its single implementation at this point. Making client components default (as they have been since the dawn of React) and saying something like "server only" would have done the trick. But with the directive "use client" you hit the mental pathway that people have around SSR. It adds just enough friction to feel like you're missing out even though it's almost orthogonal to the concept of SSR.
uryga 3y ago
> Why did they not include other companies AFAIK: the initial stages of the project involved Vercel and Shopify [edit: and Gatsby]. these companies maintain frameworks and hosting solutions for them, which makes them good partners to work on full-stack features like this. notably, the convention ("use client") came about based on early feedback from Shopify. the reason to work with framework authors first is that RSC requires a high degree of coordination/wiring across client code, server code, and the bundler. React itself only implements a couple of low-level primitives that need to be wired together by something like a framework to actually do anything useful > expecting all third-party packages, React-related or not, to buy into the "use client" directive AFAIK: non-react code has no reason to care about this directive. and on the react side, couldn't you make the same complaint about most breaking changes?

paulddraper 3y ago

Facebook open source has been quite good (React, GraphQL, Buck, PyTorch). This is...weird. How did Vercel manage that?

marksomnian 3y ago
Dan Abramov (React core team, formerly of Meta) talks about this in a Twitter thread: https://twitter.com/dan_abramov/status/1654688751342301184 https://twitter.com/dan_abramov/status/1654688751342301184 In short, it's because Vercel invested engineer-years into piloting RSCs as part of a production framework and making Next the guinea pig. Next wasn't actually the first framework to try RSCs - Hydrogen (Shopify) and Gatsby both tried early versions of it and provided feedback, but Next is the first to implement it to the point that it can be considered stable. The long-term goal is that RSCs aren't a Next-only concept - for example the Remix team said that they wouldn't implement them until they became more stable (https://twitter.com/ryanflorence/status/1678416472010260480 https://twitter.com/ryanflorence/status/1678416472010260480), but are working on it now (https://twitter.com/ryanflorence/status/1697253955376722092 https://twitter.com/ryanflorence/status/1697253955376722092). But the React team has always historically favoured trying new features in production to iterate on the API (this happened a lot internally at Meta), and this was an opportunity to do that.
- tshaddox 3y ago
  Also worth noting that after experimenting with RSCs in Hydrogen, Shopify acquired Remix and is now building Hydrogen using Remix.
  - danabramov 3y ago
    Also worth noting that Remix is working on RSC support right now.

foota 3y ago

Reading further, use client is viral, and propagates to children components.

danabramov 3y ago
"use client" is more of a bundler feature. It doesn't propagate to components per se, it affects the import tree. You can think of "use client" as a directive that says: the entire module graph below gets shipped to the client bundle.

deleted 3y ago

[deleted]

adamesque 3y ago

The reason Vercel was selected for this privilege is pretty simple, to my understanding: they volunteered and committed engineering resources to partner with the React team to work through a pretty major and experimental new API with a lot of expected breaking changes. Child of a sibling comment has more details: https://news.ycombinator.com/item?id=37408918 https://news.ycombinator.com/item?id=37408918

qudat 3y ago
Further, some react devs are now working full time for vercel. Money is to be made on both sides which is why this relationship exists.
- uryga 3y ago
  how exactly is there "money to be made" here for the React team?

TheCoelacanth 3y ago

Third-party packages don't need any directives unless they specifically want to put a client/server boundary in their component. The directive marks where the transition from server to client happens. If you aren't already starting in a server component, then you don't need to do anything to use client features.

BoorishBears 3y ago
> If you aren't already starting in a server component, then you don't need to do anything to use client features. This is a deceptive reply since the only RSC implementation in existence starts from a server component. That means that having React State, a basic building block of React that's leveraged massively across the ecosystem, is broken by default until the user adds a "use client" directive. They're 100% right that "use server" should have been the directive, and more specifically it should have been something like "use non-interactive". Server vs Client is already widely understood to be tied to SSR in a completely orthogonal manner. RSC has a much narrower value proposition that shouldn't have gotten muddied by all this.
- danabramov 3y ago
  The design you're suggesting doesn't work because it would cause server/client waterfalls everywhere, which goes against the entire purpose of the architecture. The data flows in one direction: from the server to the client. It's just physics — your server is where the data is. You're trying to move it to the client. So the code that needs to run first is the server code. This is why the data flow starts at the server. You can't fix this by changing how opting in works, or some other API design workaround. What you're fighting with is the arrow of time. As for the terminology, I agree it is confusing, but I have not seen a better suggestion yet. I shared our reasoning here (https://github.com/reactwg/server-components/discussions/4 https://github.com/reactwg/server-components/discussions/4), hope it's helpful.
  - BoorishBears 3y ago
    There's nothing about it "that doesn't work": it simply isn't as effective at getting people moving to the mental model you're prescribing. People would have mostly trucked as they have. Except people not wanting to do that mental shift was largely why they chose Next.js over a framework like Remix. Choosing a default that breaks things (forcing npm packages to label their components...) was way too heavy handed considering the tenuous nature of RSC as a whole with its single implementation at this point. Making client components default (as they have been since the dawn of React) and saying something like "server only" would have done the trick. But with the directive "use client" you hit the mental pathway that people have around SSR. It adds just enough friction to feel like you're missing out even though it's almost orthogonal to the concept of SSR.

uryga 3y ago

> Why did they not include other companies AFAIK: the initial stages of the project involved Vercel and Shopify [edit: and Gatsby]. these companies maintain frameworks and hosting solutions for them, which makes them good partners to work on full-stack features like this. notably, the convention ("use client") came about based on early feedback from Shopify. the reason to work with framework authors first is that RSC requires a high degree of coordination/wiring across client code, server code, and the bundler. React itself only implements a couple of low-level primitives that need to be wired together by something like a framework to actually do anything useful > expecting all third-party packages, React-related or not, to buy into the "use client" directive AFAIK: non-react code has no reason to care about this directive. and on the react side, couldn't you make the same complaint about most breaking changes?