3 ms·
It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.
by edflsafoiewq 2y ago
It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.
- kyleee 2y agoIt’s probably about time for that to become fashionable again
- ChocolateGod 2y agoIIRC its what frameworks like Svelte do when they hit the compiler and optimize, which makes the best of both worlds.
- wruza 2y agoThey 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 2y agoCan 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.
- division_by_0 2y agoIt's also worth noting that the Svelte signals implementation is quite performant. [0] [0] https://github.com/sveltejs/svelte/discussions/13277 https://github.com/sveltejs/svelte/discussions/13277
- JoeyJoJoJr 2y agoDo 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.
- vendiddy 2y agoIt'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.
- _heimdall 2y agoReactive 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 2y agoIt 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 2y agoThat'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.