| ▲ | edflsafoiewq 3 days ago |
| It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace. |
|
| ▲ | _heimdall 3 days ago | parent | next [-] |
| 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. |
| |
| ▲ | d357r0y3r 3 days ago | parent [-] | | 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. | | |
| ▲ | _heimdall 2 days ago | parent [-] | | 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. |
|
|
|
| ▲ | kyleee 3 days ago | parent | prev [-] |
| It’s probably about time for that to become fashionable again |
| |
| ▲ | vendiddy 3 days ago | parent | next [-] | | 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. | |
| ▲ | JoeyJoJoJr 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | ChocolateGod 3 days ago | parent | prev [-] | | IIRC its what frameworks like Svelte do when they hit the compiler and optimize, which makes the best of both worlds. | | |
| ▲ | wruza 3 days ago | parent [-] | | 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. | | |
| ▲ | MrJohz 3 days ago | parent [-] | | 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. | | |
|
|
|
