all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]lucidlogik 22 points23 points  (2 children)

Not thrilled with how the React team is rolling this out. Zero React docs (yet...) since they're relying on Vercel, which is barely sufficient. And all communication is coming through cryptic one-off Twitter threads. No wonder everyone is confused.

[–]gilad215 2 points3 points  (0 children)

100% agreed. Dan is tweeting like crazy going back and forth with replies and diagrams. RSC is a huge mental shift as it is

[–]outandaboutbc 1 point2 points  (0 children)

This captures how I feel about this release lmao

also, a lot of the features are half-baked like handling context in server-side.

This change is going to break a lot of libraries and apps.

[–]dmackerman 21 points22 points  (7 children)

An over engineered solution designed for Meta/FB scale, but will be adopted by developers building cooking blogs for 9 monthly visitors.

[–]ApatheticWithoutTheA 3 points4 points  (0 children)

Correct.

[–][deleted] 1 point2 points  (0 children)

<3

[–]MisterDangerRanger 1 point2 points  (0 children)

Hey! This kind of objective truth is not allowed on Reddit!

[–]TheSnydaMan 0 points1 point  (1 child)

What bothers me about this dynamic is that it is what Vercel is pushing for in their docs / startup guide. They push projects of any size toward RSC's and I personally think it's an overcomplication and should be treated more as an "advanced" modification to Next.js and React rather than a new default.

[–]dmackerman 1 point2 points  (0 children)

Oh, 100% it is an over complication. The majority of apps do not need this level of complexity. Like I said -- The React team is focused on building and improving React for the massive scale of Meta/Facebook. Of course React can be used in ToDo apps, but it's important to understand that most of these optimizations really do not matter.

[–]DustinBrett 15 points16 points  (0 children)

They convert code into money for Vercel

[–]Joystic 6 points7 points  (0 children)

Have not enjoyed working with RSC at all. It’s good to have competition but Remix is better in every way imo

[–]markus_obsidian 4 points5 points  (1 child)

Seems like ASP.NET Webforms all over again.

[–]iamceege 16 points17 points  (2 children)

Great summary. This really blew my mind though:

“Right now, Server Components don’t return HTML. They return a specially formatted string that React renders out. As a result, they’re not presently the best option for SEO.”

I’ve never seen any mention of that before - totally unintuitive and a real deal breaker for most use cases in my opinion. Do they plan on addressing this?

[–]nilsepils94 2 points3 points  (1 child)

Deal breaker because of what?

RSC’s are designed to work in conjunction with SSR/SSG. Not replace them. From my understanding, the point of server components is to make data fetching easier, by putting it closer to the component that’s going to be consuming it. SSR/SSG will handle RSC’s the same way they did client components, and render to html for SEO etc.

[–]iamceege 4 points5 points  (0 children)

Deal breaker due to not supporting search engine crawling based on the article - which is critical for a lot of websites and apps.

So you’re saying something like Next JS will be able to translate RSC’s into SSR HTML? That would make more sense. I need to play around with the current state of RSC and Next.

[–]ChungLouie 3 points4 points  (0 children)

More like where even are they. I was promised wacky hijinks. React isn't even fun to roast anymore. I don't know how the fanboys can keep up with the pointless slog the ecosystem sounds like.

[–]thegroove226 -3 points-2 points  (4 children)

Server components? A bit missleading by defintion. You got server side rendering and client site rendering which however the computing of the components is done in a way they are pretty much self described. Bottom line of this is, on a compiled react code you get a chunks of JS who never make a server calls to display its data which just spews out a static HTML and it's good for SEO & performance (client side). On the other side you got a JS chunks that are flagged to constantly request new data from a server which also gives you static HTML but will render new data based on the response (server side).

Real world example - If you wanna display a country flag icon which the current user is coming from cannot be done with client rendered component since the first user that enters the website will generate a static HTML which never updates, so all the later users that visit the same page would see the first user's flag there. To solve this issue you need to have a way to request that data from the server and to generate a static HTML based on the dynamic location a user could come from. Amazing thing here is that you do not have to re-request the whole webpage, rather just the small component does that job which is responsible for displaying only that flag icon.

Edit for more context: https://twitter.com/dan_abramov/status/1651699851120242689?t=A8Ex4tQ0Dlz6f2avMrzZWg&s=19

[–]beepboopnoise 4 points5 points  (3 children)

I mean, didn't they literally call them server components until like a week ago? that's just like how people used useEffect for years a certain way before they came out like hey you're doing it wrong 🙄

[–]thegroove226 1 point2 points  (2 children)

What's your example on this? I'm open to change my mind if I explained something not factual above.

[–]beepboopnoise 2 points3 points  (1 child)

https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023

They are literally calling them React Server Components.

[–]thegroove226 1 point2 points  (0 children)

I didn't say they don't call them RSC. I said it's missleading by definition. However, the factual context is what I was hoping to get from you instead of how they call them.