12 ms·

Making sense of React Server Components

118 points by joshwcomeau 3y ago

benatkin 3y ago
> This tutorial is written primarily for developers who are already using React Also good for those moving away from React, since we understand React too. Probably won't change it, but may give us things to look for in our new frameworks. A former coworker who was really into React just switched to Flutter.
- cageface 3y ago
  I just started building a new app in Flutter too after working exclusively in React for the last several years. I'm not sure I'd use Flutter for the web yet but I definitely prefer it to React Native.
  - benatkin 3y ago
    I like how Flutter is truly different. I learned just how different it is because it has a completely different problem, shader compilation jank. It shows what great risks the Flutter team took to create something innovative. It's paying off, and time will tell how big it will be! https://docs.flutter.dev/perf/shader https://docs.flutter.dev/perf/shader
    - cageface 3y ago
      I think it really comes down to Google's level of commitment to Flutter. They've done a lot of great work so far and I think it could easily become the first choice for cross platform app development if they investing in it to the degree they have so far.
    - Aldo_MX 3y ago
      Jank is addressed with the new engine that replaces Skia https://www.youtube.com/watch?v=vd5NqS01rlA&t=644s https://www.youtube.com/watch?v=vd5NqS01rlA&t=644s
idosh 3y ago
How does it handle flaky connection or even offline scenario? How does it work with service worker?
halfmatthalfcat 3y ago
It's annoying that the React team announced Server Components without a well defined spec, the wire protocol most significantly. Instead, it's a cabal between the React team and Vercel which obviously is going to give them an inherent advantage and probably steer things in their favor, rather than the broader React ecosystem as a whole.
- quonn 3y ago
  It seems like there is a project on github called simple-rsc that works without Next.
- danabramov 3y ago
  The wire protocol isn't relevant -- it's an implementation detail of React, and both the client and the server for it are open source and in the React repository. Next uses those. So will Remix, Redwood, and other RSC frameworks. If you're curious: https://github.com/facebook/react/blob/main/packages/react-client/ https://github.com/facebook/react/blob/main/packages/react-c... https://github.com/facebook/react/tree/main/packages/react-server https://github.com/facebook/react/tree/main/packages/react-s...
  - halfmatthalfcat 3y ago
    Dan, you can't deny that most (if not all) the comms from both the React team and Vercel make it obvious that Vercel is not only first-moving on RSC but working intimately with the React team to both vet the implementation and I'm sure offer (opinionated) advice on tweaks/direction. Also, links to packages with 5 line READMEs and no comments/documentation in the code might as well be called blackboxed. Yes, its open source but that's pretty much it. John or Jane Doe will have to deconstruct and/or assume the team's intention by combing through your links, https://github.com/reactwg/server-components/discussions/5 https://github.com/reactwg/server-components/discussions/5 and the (light) documentation from Vercel on how all this stuff really works. All I'm asking for is clarity and the ability to potentially create my own implementation rather than watch the "big guys" (read: frameworks) get the advantage by having access to information we don't have.
TheGeminon 3y ago
> Instead of bouncing back and forth between the client and server, we do our database query as part of the initial request, sending the fully-populated UI straight to the user. > But hm, how exactly would we do this? Couldn't help but chuckle. What mysterious technology could allow us to send an entire fully-populated UI over the web?
- benatkin 3y ago
  > What mysterious technology could allow us to send an entire fully-populated UI over the web? WebAssembly? Just kidding. But I think a lot don't realize that you could. It's pretty well supported now and a small WebAssembly library can fit in about the same size as a full page photo.
  - gabereiser 3y ago
    Vugu?
- deleted 3y ago
  [deleted]
- gabereiser 3y ago
  “As if a million voices cried out in terror and were suddenly silenced” - The full circle. When they left us, they were but learners, now they have become masters. Realizing that this nirvana exists, that people have been doing it this way for ages. That a combination of interactivity with the offloading of compute and rendering is a good thing for their performance. That grey beards really do know a thing or two. /s All sarcasm aside, having composable components server-side is only a good thing. I welcome it.
  - nwienert 3y ago
    We already had composable components server side with SSR, they just didn't query data inside the render loop. But that doesn't really gain much, if anything leads to slower overall performance as now instead of doing something like GraphQL and resolving your entire tree in a single optimized database call, you're probably waterfalling all over the place.
bdcravens 3y ago
so ... ColdFusion custom tags?
- kraig911 3y ago
  I legit spit out my coffee when I read this.
  - swyx 3y ago
    its actually something thats been discussed before https://twitter.com/floydophone/status/1462928358988156932?s=20 https://twitter.com/floydophone/status/1462928358988156932?s...
- Alifatisk 3y ago
  Haven’t heard of coldfusion in years!
xixixao 3y ago
> In order for this to work, we'd need to be able to give React a chunk of code that it runs exclusively on the server, to do the database query This is not true/it’s misleading. What you need is to be able to fetch on the server, and hydrate on the client using data from the server. This is possible with SSR and injecting into the React stream, using isomorphic (client) components. The article is great, but the reasons for RSC are more subtle/complicated than the flow of the article would imply.
- xixixao 3y ago
  You can see a live demo of this here (using Remix and https://github.com/brillout/react-streaming https://github.com/brillout/react-streaming): https://blessed-ibis-783.convex.site/ https://blessed-ibis-783.convex.site/ The relevant isomorphic data fetching hook source code is here: https://github.com/xixixao/convex-hosting/blob/main/app/hooks.ts https://github.com/xixixao/convex-hosting/blob/main/app/hook...
megaman821 3y ago
The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many caveats and such a terrible API. A magic "use client" string at the top of a file is just ridiculous. React code is nearly impossible to understand and write without extensive external documentation now. I feel sad for the future developer that has to modify this type of code ten years from now; I hope Google is good at searching decade old documentation to figure out what the hell is going on in old React code.
- paulddraper 3y ago
  > The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps array is omitted it always runs. What API would you prefer? Something more like signals?
  - cjcenizal 3y ago
    This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
    - consilient 3y ago
      That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
    - paulddraper 3y ago
      tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
    - Scarblac 3y ago
rabuse 3y ago
Hilarious that the industry is going full-circle back to server rendered pages.
- jbverschoor 3y ago
  Same thing every so many years. Waste of life
- meiraleal 3y ago
  The industry isn't, a few big players are going and trying to bring the industry but I have the impression that React is going to lose its lead in mind share in 1 year.
- danabramov 3y ago
  That's because it's not a full circle. There are plenty of subtle details that are new. The ability to interleave components written for Server and Client within a single programming model and with support for in-place refetching that doesn't destroy state is relatively novel — frankly I haven't seen something quite like it anywhere before.
lioeters 3y ago
> 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.
mattaw2001 3y ago
[flagged]
mattaw2001 3y ago
[flagged]
MPiccinato 3y ago
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 3y ago
  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 3y ago
    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 https://github.com/reactwg/server-components/discussions/4
rco8786 3y ago
I'll do what I did the last time one of these articles popped up. Word counts: complex: 2 confusing: 3
- deleted 3y ago
  [deleted]
foota 3y ago
This is my first time really reading about them, I'd assumed they'd do some ASPX style interactivity where server components updates on the server and send back html, it's interesting that they haven't tried to go for something like that, meaning this is a lot more limited in scope in some ways than I'd thought.
- marksomnian 3y ago
  If you mean updating the page as the result of a mutation, Server Actions (https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/app/building-your-application/data-f..., still in alpha) can do that - Next can re-render a route and send the newly updated UI as part of the response (this is a Next-specific feature, but I can't see why other frameworks couldn't implement a similar pattern around RSCs).
  - foota 3y ago
    Which of these examples show that? As far as I can tell the closest is the server form, but that only seems to allow the form submissipn to be handled dynamivally, but doesn't show updating the server rendered component?
    - marksomnian 3y ago
      It's not explicitly demonstrated, but the Revalidating Data example (https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations#revalidating-data https://nextjs.org/docs/app/building-your-application/data-f...) would do it - calling revalidatePath/revalidateTag from a Server Action will (if the current route matches the path/tag) cause the route to get re-rendered as part of the same round trip.
Gunax 3y ago
Server side rendering isnt special any more: https://joshcollinsworth.com/blog/antiquated-react#server-side-rendering-isnt-special-anymore https://joshcollinsworth.com/blog/antiquated-react#server-si... This blog was posted to HN a few weeks ago. The author does a really good job of summarizing React's relationship with the rest of the SPA ecosystem.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
paxys 3y ago
The last decade of web dev can be summed up as: – A bunch of smart Facebook engineers with unlimited funding decided to mess around and see just how much they could upend all the existing web paradigms, before finally concluding that conventional wisdom and the traditional server-side rendering model exist for a reason and make sense. – The entire software industry decided that every new experiment by this above group was worth ripping out and rewriting their entire codebase over, whether it made sense for their needs or not and whether it actually made their product better or not. I have not been too deep into the weeds of it myself but have been interacting with FE teams at my company enough to see what a charade it all is. "This React thing is cool, and everyone is talking about it. Let's move some of our existing JS components over to it and see how things turns out." "We need to do a top-down rewrite of the entire app in React." "We're going to need the infra team to set up a GraphQL API layer for us. It can't be that hard, right?" "Hmm, initial page loads are too slow. Hey infra team, can you set up a render farm of Node.js servers so we can do SSR?" "Whoa, functional components are cool! We need to do another top-down rewrite and get rid of all the silly classes." "We have a small team dedicated to investigating server components, and if the prototype looks good then we'll switch over to Next.js and rewrite our FE + API stack." I'm sure my company wasn't the only one that caught this virus. I shudder to think just how much money and productivity has been wasted industry-wide over the obsession with this framework.
- nwienert 3y ago
  I don’t think you could be more off, honestly. React revolutionized frontend development and made it dramatically better. Server side rendering for React has existed since very early in its lifetime. The rest of the snark looks silly in context of the above two points.
  - paulddraper 3y ago
    But haruff harruf everything is stupid and I don't see any difference in what I can do with the web now vs 15 years ago haruff haruff
  - jaredcwhite 3y ago
    [flagged]
DanielHB 3y ago
A lot of people are complaining about NextJS + Vercel lock-in RSC locks you into their hosting solution and the way they suggest you to use it also locks you into NextJS way of building your backend data layer (ie PHP/JSP/ASP-like with our without MVC) But their routing things locks you into NextJS as a framework. Just remember how much people complained about migrating from react-router v4 to v5 (or was it v5 to v6?). Migrating from a routing solution is a huge pain in the ass. I am still unconvinced that file-system based routing is better. It is at best a replacement for lack of guidelines in most routing libs on how to organise your components for routing. I am also very weary of anything that takes over the bundler, bundling is a hard problem and just outsourcing it is asking for trouble. But I understand why a lot of people don't want to deal with it, it takes a huge codebase for bundling to become a big issue. I am looking forward to Bun: https://bun.sh/ https://bun.sh/ Which promises to reduce the tooling headaches to get a project going without using a bunch of frameworks. Their bundler though is still nowhere near ready so I wouldn't recommend it for frontend projects yet. Using Bun just to run nextjs/webpack/whatever on top of it also doesn't seem like a good solution to me. Bun might support RSC in the future, but in my opinion RSC is a very specialised tool to be used only in a few critical places in your code and it is scary how Vercel is pushing for it so hard in their docs. You have to remember that the average new frontend developer now uses "create-next-app" not "create-react-app" and is introduced to RSC right away
- uryga 3y ago
  > But their routing things locks you into NextJS as a framework. I'm confused by this -- how is a framework supposed to offer routing in a way that doesn't "lock you in"? are you "locked into" React Router if you use that? what's the alternative? > RSC locks you into [Vercel's] hosting solution how? you can self-host it if you want.
  - DanielHB 3y ago
    > are you "locked into" React Router if you use that? Every dependency if large enough has lock-in. The problem with NextJS is how coupled everything is. In NextJS if you decide to stop using it you need to also rewrite your routing. React-router doesn't care about your bundler, or your deployment flows or your use of RSC, etc.

118 points by joshwcomeau 3y ago

> This tutorial is written primarily for developers who are already using React Also good for those moving away from React, since we understand React too. Probably won't change it, but may give us things to look for in our new frameworks. A former coworker who was really into React just switched to Flutter.

cageface 3y ago
I just started building a new app in Flutter too after working exclusively in React for the last several years. I'm not sure I'd use Flutter for the web yet but I definitely prefer it to React Native.
- benatkin 3y ago
  I like how Flutter is truly different. I learned just how different it is because it has a completely different problem, shader compilation jank. It shows what great risks the Flutter team took to create something innovative. It's paying off, and time will tell how big it will be! https://docs.flutter.dev/perf/shader https://docs.flutter.dev/perf/shader
  - cageface 3y ago
    I think it really comes down to Google's level of commitment to Flutter. They've done a lot of great work so far and I think it could easily become the first choice for cross platform app development if they investing in it to the degree they have so far.
  - Aldo_MX 3y ago
    Jank is addressed with the new engine that replaces Skia https://www.youtube.com/watch?v=vd5NqS01rlA&t=644s https://www.youtube.com/watch?v=vd5NqS01rlA&t=644s

idosh 3y ago

How does it handle flaky connection or even offline scenario? How does it work with service worker?

halfmatthalfcat 3y ago

It's annoying that the React team announced Server Components without a well defined spec, the wire protocol most significantly. Instead, it's a cabal between the React team and Vercel which obviously is going to give them an inherent advantage and probably steer things in their favor, rather than the broader React ecosystem as a whole.

quonn 3y ago
It seems like there is a project on github called simple-rsc that works without Next.
danabramov 3y ago
The wire protocol isn't relevant -- it's an implementation detail of React, and both the client and the server for it are open source and in the React repository. Next uses those. So will Remix, Redwood, and other RSC frameworks. If you're curious: https://github.com/facebook/react/blob/main/packages/react-client/ https://github.com/facebook/react/blob/main/packages/react-c... https://github.com/facebook/react/tree/main/packages/react-server https://github.com/facebook/react/tree/main/packages/react-s...
- halfmatthalfcat 3y ago
  Dan, you can't deny that most (if not all) the comms from both the React team and Vercel make it obvious that Vercel is not only first-moving on RSC but working intimately with the React team to both vet the implementation and I'm sure offer (opinionated) advice on tweaks/direction. Also, links to packages with 5 line READMEs and no comments/documentation in the code might as well be called blackboxed. Yes, its open source but that's pretty much it. John or Jane Doe will have to deconstruct and/or assume the team's intention by combing through your links, https://github.com/reactwg/server-components/discussions/5 https://github.com/reactwg/server-components/discussions/5 and the (light) documentation from Vercel on how all this stuff really works. All I'm asking for is clarity and the ability to potentially create my own implementation rather than watch the "big guys" (read: frameworks) get the advantage by having access to information we don't have.

TheGeminon 3y ago

> Instead of bouncing back and forth between the client and server, we do our database query as part of the initial request, sending the fully-populated UI straight to the user. > But hm, how exactly would we do this? Couldn't help but chuckle. What mysterious technology could allow us to send an entire fully-populated UI over the web?

benatkin 3y ago
> What mysterious technology could allow us to send an entire fully-populated UI over the web? WebAssembly? Just kidding. But I think a lot don't realize that you could. It's pretty well supported now and a small WebAssembly library can fit in about the same size as a full page photo.
- gabereiser 3y ago
  Vugu?
deleted 3y ago
[deleted]
gabereiser 3y ago
“As if a million voices cried out in terror and were suddenly silenced” - The full circle. When they left us, they were but learners, now they have become masters. Realizing that this nirvana exists, that people have been doing it this way for ages. That a combination of interactivity with the offloading of compute and rendering is a good thing for their performance. That grey beards really do know a thing or two. /s All sarcasm aside, having composable components server-side is only a good thing. I welcome it.
- nwienert 3y ago
  We already had composable components server side with SSR, they just didn't query data inside the render loop. But that doesn't really gain much, if anything leads to slower overall performance as now instead of doing something like GraphQL and resolving your entire tree in a single optimized database call, you're probably waterfalling all over the place.

bdcravens 3y ago

so ... ColdFusion custom tags?

kraig911 3y ago
I legit spit out my coffee when I read this.
- swyx 3y ago
  its actually something thats been discussed before https://twitter.com/floydophone/status/1462928358988156932?s=20 https://twitter.com/floydophone/status/1462928358988156932?s...
Alifatisk 3y ago
Haven’t heard of coldfusion in years!

xixixao 3y ago

> In order for this to work, we'd need to be able to give React a chunk of code that it runs exclusively on the server, to do the database query This is not true/it’s misleading. What you need is to be able to fetch on the server, and hydrate on the client using data from the server. This is possible with SSR and injecting into the React stream, using isomorphic (client) components. The article is great, but the reasons for RSC are more subtle/complicated than the flow of the article would imply.

xixixao 3y ago
You can see a live demo of this here (using Remix and https://github.com/brillout/react-streaming https://github.com/brillout/react-streaming): https://blessed-ibis-783.convex.site/ https://blessed-ibis-783.convex.site/ The relevant isomorphic data fetching hook source code is here: https://github.com/xixixao/convex-hosting/blob/main/app/hooks.ts https://github.com/xixixao/convex-hosting/blob/main/app/hook...

megaman821 3y ago

The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many caveats and such a terrible API. A magic "use client" string at the top of a file is just ridiculous. React code is nearly impossible to understand and write without extensive external documentation now. I feel sad for the future developer that has to modify this type of code ten years from now; I hope Google is good at searching decade old documentation to figure out what the hell is going on in old React code.

paulddraper 3y ago
> The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps array is omitted it always runs. What API would you prefer? Something more like signals?
- cjcenizal 3y ago
  This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
  - consilient 3y ago
    That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
  - paulddraper 3y ago
    tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
  - Scarblac 3y ago

rabuse 3y ago

Hilarious that the industry is going full-circle back to server rendered pages.

jbverschoor 3y ago
Same thing every so many years. Waste of life
meiraleal 3y ago
The industry isn't, a few big players are going and trying to bring the industry but I have the impression that React is going to lose its lead in mind share in 1 year.
danabramov 3y ago
That's because it's not a full circle. There are plenty of subtle details that are new. The ability to interleave components written for Server and Client within a single programming model and with support for in-place refetching that doesn't destroy state is relatively novel — frankly I haven't seen something quite like it anywhere before.

lioeters 3y ago

> 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.

mattaw2001 3y ago

[flagged]

mattaw2001 3y ago

[flagged]

MPiccinato 3y ago

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 3y ago
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 3y ago
  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 https://github.com/reactwg/server-components/discussions/4

rco8786 3y ago

I'll do what I did the last time one of these articles popped up. Word counts: complex: 2 confusing: 3

deleted 3y ago
[deleted]

foota 3y ago

This is my first time really reading about them, I'd assumed they'd do some ASPX style interactivity where server components updates on the server and send back html, it's interesting that they haven't tried to go for something like that, meaning this is a lot more limited in scope in some ways than I'd thought.

marksomnian 3y ago
If you mean updating the page as the result of a mutation, Server Actions (https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/app/building-your-application/data-f..., still in alpha) can do that - Next can re-render a route and send the newly updated UI as part of the response (this is a Next-specific feature, but I can't see why other frameworks couldn't implement a similar pattern around RSCs).
- foota 3y ago
  Which of these examples show that? As far as I can tell the closest is the server form, but that only seems to allow the form submissipn to be handled dynamivally, but doesn't show updating the server rendered component?
  - marksomnian 3y ago
    It's not explicitly demonstrated, but the Revalidating Data example (https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations#revalidating-data https://nextjs.org/docs/app/building-your-application/data-f...) would do it - calling revalidatePath/revalidateTag from a Server Action will (if the current route matches the path/tag) cause the route to get re-rendered as part of the same round trip.

Gunax 3y ago

Server side rendering isnt special any more: https://joshcollinsworth.com/blog/antiquated-react#server-side-rendering-isnt-special-anymore https://joshcollinsworth.com/blog/antiquated-react#server-si... This blog was posted to HN a few weeks ago. The author does a really good job of summarizing React's relationship with the rest of the SPA ecosystem.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

paxys 3y ago

The last decade of web dev can be summed up as: – A bunch of smart Facebook engineers with unlimited funding decided to mess around and see just how much they could upend all the existing web paradigms, before finally concluding that conventional wisdom and the traditional server-side rendering model exist for a reason and make sense. – The entire software industry decided that every new experiment by this above group was worth ripping out and rewriting their entire codebase over, whether it made sense for their needs or not and whether it actually made their product better or not. I have not been too deep into the weeds of it myself but have been interacting with FE teams at my company enough to see what a charade it all is. "This React thing is cool, and everyone is talking about it. Let's move some of our existing JS components over to it and see how things turns out." "We need to do a top-down rewrite of the entire app in React." "We're going to need the infra team to set up a GraphQL API layer for us. It can't be that hard, right?" "Hmm, initial page loads are too slow. Hey infra team, can you set up a render farm of Node.js servers so we can do SSR?" "Whoa, functional components are cool! We need to do another top-down rewrite and get rid of all the silly classes." "We have a small team dedicated to investigating server components, and if the prototype looks good then we'll switch over to Next.js and rewrite our FE + API stack." I'm sure my company wasn't the only one that caught this virus. I shudder to think just how much money and productivity has been wasted industry-wide over the obsession with this framework.

nwienert 3y ago
I don’t think you could be more off, honestly. React revolutionized frontend development and made it dramatically better. Server side rendering for React has existed since very early in its lifetime. The rest of the snark looks silly in context of the above two points.
- paulddraper 3y ago
  But haruff harruf everything is stupid and I don't see any difference in what I can do with the web now vs 15 years ago haruff haruff
- jaredcwhite 3y ago
  [flagged]

DanielHB 3y ago

A lot of people are complaining about NextJS + Vercel lock-in RSC locks you into their hosting solution and the way they suggest you to use it also locks you into NextJS way of building your backend data layer (ie PHP/JSP/ASP-like with our without MVC) But their routing things locks you into NextJS as a framework. Just remember how much people complained about migrating from react-router v4 to v5 (or was it v5 to v6?). Migrating from a routing solution is a huge pain in the ass. I am still unconvinced that file-system based routing is better. It is at best a replacement for lack of guidelines in most routing libs on how to organise your components for routing. I am also very weary of anything that takes over the bundler, bundling is a hard problem and just outsourcing it is asking for trouble. But I understand why a lot of people don't want to deal with it, it takes a huge codebase for bundling to become a big issue. I am looking forward to Bun: https://bun.sh/ https://bun.sh/ Which promises to reduce the tooling headaches to get a project going without using a bunch of frameworks. Their bundler though is still nowhere near ready so I wouldn't recommend it for frontend projects yet. Using Bun just to run nextjs/webpack/whatever on top of it also doesn't seem like a good solution to me. Bun might support RSC in the future, but in my opinion RSC is a very specialised tool to be used only in a few critical places in your code and it is scary how Vercel is pushing for it so hard in their docs. You have to remember that the average new frontend developer now uses "create-next-app" not "create-react-app" and is introduced to RSC right away

uryga 3y ago
> But their routing things locks you into NextJS as a framework. I'm confused by this -- how is a framework supposed to offer routing in a way that doesn't "lock you in"? are you "locked into" React Router if you use that? what's the alternative? > RSC locks you into [Vercel's] hosting solution how? you can self-host it if you want.
- DanielHB 3y ago
  > are you "locked into" React Router if you use that? Every dependency if large enough has lock-in. The problem with NextJS is how coupled everything is. In NextJS if you decide to stop using it you need to also rewrite your routing. React-router doesn't care about your bundler, or your deployment flows or your use of RSC, etc.