alt Hacker NewsI still don't get why RSC is better. This post takes things for granted that don't seem obvious to me. Why would I want heavy rendering tasks to all be done on my wimpy aws box instead of the clients macbooks and iphones?
Shipping moment for dates is a pain sure but that can be chunked and cached too? It's hard to imagine the benefit of reducing bundle by X kbs could really be worth doing a roundtrip to server whenever I need format a date in the UI.
RSC seems like something only library maintainers like, although I appreciate tanstack not forcing them down my throat like next I guess.
Replies
It's a really weird situation, but using public transport WiFi cured me of this thinking.
The amount of times that the initial HTML, CSS and JS came through, but then choked on fetching the page content was insane. Staring at a spinner is more insulting than the page just not loading.
That being said, I'm not a huge fan of RSCs either. Dumping the entire VDOM state into a script tag then loading the full React runtime seems like a waste of bandwidth.
Just because data can be rendered to DOM on the client doesn't mean it always should be.
I'll try to render HTML wherever the data is stored. Meaning, if the data lives in a hosted database I'll render on the server. If data is only stored on the client, I'll render there.
Its less about bundle size in my opinion and more about reduced complexity and data security.
That said, I've never been a fan of RSC and don't see it solving the "reduced complexity" goal.
Why should a low-powered Android phone be downloading and running a full Markdown parser or syntax highlighter? Stuff like that is obviously something that should be handled by the server and just returned as final HTML.
Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server. So that means that the db queries and stuff are not even initiated until the client has the bundle and runs it, vs with RSC that stuff is all launched the moment the first request comes in from the user.
One example is that I have a fancy visualization in my app that is rendered in the server via RSC and just some interactive tidbits get sent to the client. If I packaged the whole visualization library it would have bloated my bundle size but instead I ship barely any JS and still get a nice interactive vector data viz experience. And the code just looks like normal react component nesting more or less.
If your use-cases don't benefit from RSC performance characteristics then they probably aren't outright better.
But I do think they're a compelling primitive from a DX standpoint, since they offer more granularity in specifying the server/client boundary. The TanStack Composite/slots API is the real selling point, IMO, and as far as I can tell this API is largely (entirely?) thanks to RSCs.
SEO is a good reason.
Because with RSC you don't have a shitload of loading indicators and layout shifts.
[dead]
The article lists the significant performance gains. Why render on wimpy phones over bad network when a cheap aws box can do it for you?
That aside, Next.js and the recent related vulnerabilities made me weary of RSC and I struggle to see the benefit of RSCs over the previous server side rendered and hydrated model. Chances are TanStack will do a better job than Vercel and yet the bumpy ride of the last few years tarnished the whole idea.