Hacker News new | ask | show | jobs
by skydhash 382 days ago
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).
1 comments
kaoD 382 days ago
> 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?

link
skydhash 382 days ago
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).

link
kaoD 382 days ago
> 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?

link
skydhash 382 days ago
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.

link