Hacker News new | ask | show | jobs
by jjj123 239 days ago
I’m confused by your comment. Signals do reduce manual render management.

By default, usestate causes unnecessary rerenders which signals avoid (all automatically).

2 comments

The OP is referring to the old days of javascript, where the UI was directed programatically and imperatively, e.g.

<div id="myoutput">Enter a name</div>

<input type="text" onchange="document.getElementById('myoutput').innerText = `Hello {name}!`" />

One upside of this approach is that the only subtree that needs to be re-rendered is the specific element whose state got mutated.

Another upside of this approach is that the code doing the mutation is very close to the actual UI element that triggered it. Of course, this rapidly turns into a downside as the size of the codebase grows...

It's not automatic though. Theres function calls() and you must createSignal for every derived value.

When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity.

The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.

hang on, least compared to what? other frameworks (eg. VueJS, especially older versions) have less boilerplate than react
have you tried svelte 3/4?
Svelte:

  let doubled = $derived(count * 2);
React:

  const doubled = count * 2
React is the most inefficient in terms of performance (after imgui); it recomputes everything on every event like mousemove. It was probably made for simple forms with tens of variables.
I explicitly said svelte 3 and 4, while runes have they pro and I appreciate them, svelte was terser before.
Oh sry, I thought Svelte introduced runes in v4, not 5.

I find it pointless to argue about old versions of Svelte and Vue, when their drawbacks have already been addressed by their own creators [^1].

[^1]: https://svelte.dev/blog/svelte-5-is-alive