Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.


I’m confused by your comment. Signals do reduce manual render management.

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


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


> The whole point of React was to react to state changes automatically.

It isn't, given that React requires you to provide an array of dependencies when using useMemo and useEffect. The point of React is to automatically update the DOM when a virtual DOM tree gets modified.


that's the theory, but it's quite easy to end up needing to micromanage react to avoid pathological rendering scenarios


Yeah, I'm interested to learn more about signals, but the article seems to miss the whole point of brute-force state updates -- less cognitive complexity.


I can understand the point, and the fact that in virtual dom implementations you in general specify the state -> view mapping and don't need to distinguish between first render and updates. However, practically and personally I find working with signals way simpler, and that is even without considering the debugging experience.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: