Hacker News Reader

Comment by edflsafoiewq | Hacker News Reader

It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.

Reactive view libraries exist to hide those details. I think the OP is proposing that the benefit of reactive views/state isn't worth the cost and complexity.

It is absolutely worth the cost and complexity. The cost and complexity of building a web application using some home grown vanilla JS system will end up being a horrible engineering decision most of the time.

There have been zero times in my career where I thought "hmm, maybe we shouldn't have build this thing in React and let's just go back to page scripts." If you're building landing pages and websites, then okay. But that's not most of what we're all hired to build these days.

That's way too dependent on context to say the cost is always worth the complexity.

On a team that is experienced in react, or a project that is heavily dependent on client side rendering react (or similar) make sense.

On a team that is more backend focused or a project that is CRUD heavy and generally rendering state that persists on the server, it could very well make sense to lean on server rendered HTML with small bits of JS scripts for interactivity.

We as an industry way over tilted on client-side rendering. If you're building Facebook or Figma or Discord, sure maybe CSR is a must. For most websites you don't need much CSR though, and if you're only using it for small bits of interactivity you may be better offer foregoing the complexity of a framework and taking responsibility for the full render pipeline.

It’s probably about time for that to become fashionable again

IIRC its what frameworks like Svelte do when they hit the compiler and optimize, which makes the best of both worlds.

They still nail "state" to element trees, which creates unbenchmarkable but real update costs. Svelte does better than react, but only within the same paradigm.

Can you describe what you mean by that a bit more? As I understand it, with the new signals-based system in Svelte, updating data directly updates the DOM.

It's also worth noting that the Svelte signals implementation is quite performant. [0]

[0] https://github.com/sveltejs/svelte/discussions/13277

Do you mean subscribing to events/callbacks, manually managing object lifecycle, manually inserting list elements, keeping it in sync with the state, etc, etc. Because that was all friggen horrible. Maybe new approaches could make it less horrible, but there is no way I’d go back to what it was like before React. If anything, I want everything to be more reactive, more like immediate mode rendering.

It's easy to forget how tedious things used to be before React became popular.

Keeping data in sync with the UI was a huge mental burden even with relatively simple UIs. I have no desire to go back to that.

Reply on news.ycombinator.com