Hacker News Reader

Comment by randomuxx | Hacker News Reader

Maybe I'm slow, but after countless posts about RSC, I still don't get the appeal.

Is it really worth the headache and extra complexity?

Caveat: I've used Vue more than any other FE library/framework, but for the last 3 years I worked exclusively with React (via Next—app router). The company I worked (I left in Jan) for jumped on this RSC train as soon as it was released and boy,oh boy was it a mess! We ofteb got direct support from Vercel when our shit will break or not work as expected...

To say the app was slow and behaved unexpected would be an understatement.

Eventually, they had to rewrite everything back as a SPA.

View on HN

I think RSC itself is pretty solid by this point but frameworks around it (primarily Next.js) are still somewhat rough (and were much rougher during the initial App Router release). Hard to say more without knowing what kind of issues you were hitting.

I'm posting because I find the technology interesting. I don't have a goal of convincing you to use or adopt it. I sometimes write about specific aspects that I find appealing but YMMV.

Fair Dan, and I appreciate your response.

I also hope you understand I wrote this based on my experience with it. ♥

Sure! Do you recall what kind of issues or bugs you were hitting?

That is exactly the point, due to trying to cater to the hype FE culture, many SaaS providers only make React and Next.js SDKs available for their products and extension points.

So just like it happens in some many cases in our fashion driven industry, we get dragged into using tools we don't agree with, or be busy with yak shaving adding support for other tooling.

You are right that there is no appeal. Besides the people pushing for it, which are related to the project, I've not see any project talking about the benefits of using it. React is consolidated but it doesn't mean the maintainers can evolve it the way they want. The push to RSC will undoubtedly kills React.

Maybe it's where I'm imagining we're headed (and not where we're actually headed) but I think it will bring us into the sweet spot that I want/need: good old PHP-like server-rendered sites (or even static pages) with custom interactive components (think e.g. forms with client-side validation) without the mess that mixing PHP+jQuery used to be.

Server rendering is enough for the 80% use case. Browsers are optimized for it. Sprinkle interactivity without the impedance mismatch of jQuery and you're in heaven. No more overengineered state syncing between client and server. Just. Fetch. HTML.

Currently frameworks are trying to shoehorn it into the 2018 React mindset but that's not what I think is needed for them to succeed.

You either make presentation the server job or the client job. Spreading it between the two results in the same trouble that distributed systems are trying to solve to this day. At least backend have a reason for going the distributed route (resources and risk management).

> You either make presentation the server job or the client job

Is that your axiom or do you have any justification? I just don't agree with it.

Why should the server know about a datepicker's internal details?

It's all relate to consistency. If presentation is the job of the server (html templates), the server is the source of truth and the client state is expected to be transient. That is a good model for most web applications including this forums.

There's some case where local state is more important (figma, google maps, chat app) and the backend is expected to act as a data source with a domain-specific API. Any mixture between the two and you will make the separation between the two domain (server concerns and client concerns) at the wrong place, making the design more complex (however well you hide it behind the curtains).

> If presentation is the job of the server (html templates), the server is the source of truth and the client state is expected to be transient.

Which is exactly why the client state should be transient non-application state like datepickers, dropdowns, text boxes, etc. and it does not belong in the server (essentially what jQuery was used for back in the day, interactive sprinkles). And the other way around.

Perhaps you agree with me but there was something lost in translation?

Something was lost. I was arguing either send the presentation layer as data to the web browser as resources, or send data that from which the browser and the UI library (react, svelte,...) will derives the UI from.

RSC does a weird split where the engine is the same on both ends instead of a clear separation layer where one does not need to know about each other. I much prefer HTMX approach (samey old backend where you mostly take care of everything in the frontend) and Laravel Livewire approach (where you take care of everything backend side, with optional client side scripting).

No need to reinvent the world to fix a single problem.

I think RSC is trying to answer the question, “How can we make server rendering and sprinkles of interactivity composable?” What if you want your sprinkles to have server rendered content inside of them, each of which may contain other interactive/dynamic elements?

I posit that any composable version of sprinkles or the “island architecture” will closely resemble RSC.

Only a small fraction of apps will ever use the full power of the RSC architecture. However, the React team doesn’t build apps, they build primitives for building apps. And good primitives are composable.

Yeah that is the right answer imo.

What they did wrong tho was to morph React into this mess. RSC should be React Server and live along React DOM and React Native, something almost unrelated to the previous concept of React. But we got this an entangled mess.

Reply on news.ycombinator.com