Making sense of React Server Components

https://www.joshwcomeau.com/react/server-components/

by joshwcomeau • 3 years ago

118 164 3 years ago

benatkin3• 3 years 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.

cageface2• 3 years 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.

benatkin3• 3 years 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

idosh• 3 years ago

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

halfmatthalfcat2• 3 years 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• 3 years ago

It seems like there is a project on github called simple-rsc that works without Next.

danabramov8• 3 years 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-c...

https://github.com/facebook/react/tree/main/packages/react-s...

halfmatthalfcat2• 3 years 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 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• 3 years 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?

benatkin3• 3 years 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.

gabereiser3• 3 years ago

Vugu?

gabereiser3• 3 years 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.

nwienert6• 3 years 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.

paulddraper17• 3 years ago

The Star-Bellied Sneetches

bdcravens• 3 years ago

so ... ColdFusion custom tags?

kraig911• 3 years ago

I legit spit out my coffee when I read this.

swyx• 3 years ago

its actually something thats been discussed before https://twitter.com/floydophone/status/1462928358988156932?s...

Alifatisk• 3 years ago

Haven’t heard of coldfusion in years!

xixixao2• 3 years 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.

xixixao2• 3 years ago

You can see a live demo of this here (using Remix and https://github.com/brillout/react-streaming): 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/hook...

megaman821• 3 years 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.

paulddraper17• 3 years 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• 3 years 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

SinParadise5• 3 years ago

Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way.

I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it.

You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.

foota4• 3 years ago

Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.

toastercat11• 3 years ago

The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this."

What API would you prefer? Something more like signals?

Yes. Or full tree redraws like Mithril.js did 8 years ago.

danielvaughn4• 3 years ago

This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc).

useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.

Izkata2• 3 years ago

It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...

bakugo• 3 years ago

I hope Google is good at searching decade old documentation

Google isn't even good at searching recent documentation, from my experience.

champagnepapi• 3 years ago

Agreed. IMO, it all started with Hooks. Things really went downhill from there. useEffect is terrible! Example, how easy it to forget the dependency array?! Because of that, you have to setup linting rules to fix the poor API provided by that hook...

hotnfresh3• 3 years ago

Hooks felt like a big make-work project to let folks claim high-impact commits on a project that didn’t really need any of those, anymore.

paulddraper17• 3 years ago

HN is a funny place.

A useful feature that an insane majority of React devs have come to prefer is "downhill."

Kids these days.

Gunax3• 3 years ago

Every other framework not only has its own implementation of hooks, but notably: every one of them is faster, smarter, easier to write, or a combination of all three.

I agree that useEffect is bad.

But there are other SPA frameworks that do things better. In fact, just about any other framework does things better.

orangepanda• 3 years ago

You dont have to specify the dependency array, it’s an optional optimisation.

johngalt2600• 3 years ago

Agreed. React is great but I really do not enjoy writing it. Much prefer Vue

fidotron• 3 years ago

It will turn out to be a great conspiracy where the React team are being encouraged to make it so only LLMs can make sense of React code in future.

vlod2• 3 years ago

I switched to React when jQuery (and particularly storing state in the DOM and lots of custom events called) became a PITA.

I don't feel that React has reached that tipped point yet, but when it does I'm hoping we'll all move to Sveltekit or something like it.

mattgreenrocks2• 3 years ago

I despise almost every single web framework written in the last decade. They always feel like byzantine monoliths of complexity built from tons of layers over existing libraries. They invent tons of concepts, always require patching, and have an army of sycophants who believe building a web framework is basically rocket science and only a select few are ever capable of such a feat.

SvelteKit is the first piece of web tech that I actually enjoy using. It’s the rare piece of tech that knows its lane, stays in it, and excels at it. It is marked by fewer features that work well together vs lots of features that sort of work well together.

You can read the docs in an hour or two and then start to get an understanding of what it’s doing.

Basically, it feels like it was made by someone who really understands the medium, thought deeply about how to distill that, and iterated to improve on it. (I get same vibes from Vue, but don’t have much experience there)

phendrenad2• 3 years ago

This is how it always goes. JQuery was a response to browsers having poor standardization. Then it became a larger and larger ecosystem, and the code owners started getting megalomaniacal (I'm sorry, "live" is deprecated, please us the function "on" which does the exact same thing, we just liked the name better, thank you for complying). It became an ecosystem. Every 3rd party library was designed to integrate with JQuery. Soon there was JQuery UI, a UI library for adding modal dialogs and tooltips.

And then someone realized that browsers had long since reached standards parity, and javascript engines were getting really fast, and re-rendering the DOM was GPU-accelerated, and we just needed a simple little library. And Angular and React were born (and Ember but we don't speak of satan in this house).

React feels like it's following the exact same trajectory. It was created out of necessity, it was the best framework for a given point in time, but it's being stretched to handle the changing landscape, and it's feeling very kludgey. I expect that soon, very soon, someone will release the new paradigm. Probably just as soon as WASM is able to manipulate the DOM without JS hacks, which has been on the roadmap since before there was a road.

Exuma2• 3 years ago

How do devs generally feel about Vue 3?

So far it seems really amazing even for the most complex apps. I’ve built 5 nontrivial apps with 2 being 2+ year projects

I haven’t found a “ceiling” yet

lioeters• 3 years 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.

paulddraper17• 3 years ago

Facebook open source has been quite good (React, GraphQL, Buck, PyTorch).

This is...weird. How did Vercel manage that?

marksomnian3• 3 years ago

Dan Abramov (React core team, formerly of Meta) talks about this in a Twitter thread: 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), but are working on it now (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.

foota4• 3 years ago

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

danabramov8• 3 years 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.

adamesque• 3 years 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

qudat• 3 years 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.

TheCoelacanth2• 3 years 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.

BoorishBears5• 3 years 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.

uryga5• 3 years 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?

rabuse• 3 years ago

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

jbverschoor• 3 years ago

Same thing every so many years. Waste of life

meiraleal2• 3 years 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.

danabramov8• 3 years 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.

MPiccinato• 3 years 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).

BoorishBears5• 3 years 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)

danabramov8• 3 years 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

silenthoughts2• 3 years ago

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

danabramov8• 3 years ago

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

uryga5• 3 years ago

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.

rco8786• 3 years ago

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

complex: 2

confusing: 3

foota4• 3 years 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.

marksomnian3• 3 years ago

If you mean updating the page as the result of a mutation, Server Actions (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).

foota4• 3 years 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?

Gunax3• 3 years ago

Server side rendering isnt special any more:

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.

paxys• 3 years 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.

nwienert6• 3 years 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.

paulddraper17• 3 years 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

pjmlp2• 3 years ago

Doing Web related stuff since 1998, the only revolution is cargo cult from FB stuff, while refusing to support Web components like all other frameworks.

Exuma2• 3 years ago

I still think one way data flow is profound for complex frontend UIs. The idea of making something as complex as Facebook ad manager without it sounds true nightmare level

I personally love vue and single page templates (I hate jsx)

SSR is stil a good option i think for complex apps

technion• 3 years ago

Don't forget "functions that do totally normal things now need to be rewritten as a hook".

paulddraper17• 3 years ago

If you are writing functions that do totally normally things as hooks, you are indeed doing it wrong.

Hooks are for stateful code.

silenthoughts2• 3 years ago

I do agree with most of this. I work with React on a daily basis and, while it has made things much easier than using something like jQuery or writing vanilla Javascript, I do think they're adding features that is making it more complicated to use. I still can't wrap my head around NextJS and some of the things it is doing. I prefer not to use the new features at this point.

DanielHB5• 3 years ago

People were doing SPAs way before react came around (and it took a few years for it become popular), I myself had a jQuery-based SPA a few years before React was released and when I saw React I was like: "this solves all of the problems my codebase has"

React was more of a replacement for jQuery/BackboneJS/MooTools/Angular/etc than a replacement for PHP/JSP/ASP/etc

pjmlp2• 3 years ago

See Sitecore fully embracing NextJS, moving away from .NET, with Vercel sponsored keynotes.

DanielHB5• 3 years 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/

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

uryga5• 3 years 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.

DanielHB5• 3 years 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.

Making sense of React Server Components

Related Stories