Hacker News Reader

> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird.

It's not that the properties shouldn't be updated it's that in React the whole subtree gets completely re-rendered, with a potentially big performance cost. Svelte just changes the relevant bit of the DOM, like a single class attribute or whatever, and leaves everything else be, this feature alone is what made me switch. In addition to baseline performance benefits certain things which are really awkward in React (e.g. animated transitions) become non-issues.

>Feeling like you have to stick with React is a state of mind - you can change that with enough effort.

I really appreciate your optimism about switching to a different framework/ etc. and I would have felt the same earlier in my career where I didn't have so many non work commitments, financial and otherwise. But to me now this reads as wishful thinking; switching track is difficult, especially when your existing skill set represents a large chunk of the demand in the marketplace. (And I say this having recently sucessfully made the switch from React to Svelte)

No doubt there are individuals with circumstances that make switching tech stack harder due to the demands on their time elsewhere, and I feel for those devs being stuck on a stack they don't enjoy (I was a PHP dev for a decade, I understand their pain). But I also think that those problems are temporary. You might be stuck on something for a few years, but in the grand plan that is your career spending even a couple of hours a week to move to something that you don't hate is worthwhile.

It'd be awesome if everyone who dislikes React could spend a month immediately learning Svelte or Solid, or Kotlin or Swift, but that's obviously not possible. All I'm saying is that if you're not doing anything to change your future then you should seriously consider if the problem is as bad as you might say it is.

> switching track is difficult [...] (And I say this having recently sucessfully made the switch from React to Svelte)

Having developed with Angular and React, and dabbling with Vue, I have to say that Svelte has the best ergonomics of the lot, and the language tutorial is so approachable. I haven't had to think about performance or state to the degree that I have in other frameworks. Any workplace could easily skill up a Svelte dev from a React dev.

> Svelte just changes the relevant bit of the DOM,

Because Svelte is mutable state galore. I thought we all agreed to say no thanks to that.

Yeah, but atleast in Svelte it's explicit, and you can if you wish write svelte as if ste were immutable. Anecdotal, but still, I've had fewer bugs (particularly wierd UI glitches) in Svelte than I ever did in React. I just like Svelte for the types of project I work on.

Tangent: the idea that "we all agreed to say no thanks to that" is kind of symptomatic of broader issues I have with web dev. i.e. that there's very little recognition that different tools have different uses and knowing when to pick which is part of the job. Working with wood you wouldn't apply the same practices and methods to building the timber frame of 2 story house as you would to making an intricately carved toy elephant. Why when working with the materials of the web, HTML/CSS/JS, do we assume there's a best and right why to do it: "you must write tests!", "avoid using z-index!", "separate content and form", "immutable state!"; these are all the right answer in some situation and not in others.

> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior.

Isn't this the whole selling point of Solid's signals? If a child component receives its props from the parent as signals, and asks the parent to fetch some data and update the state, then the child won't rerender; only the bits that are consuming the signals will. Fine-grained reactivity, they call it.

I've not used Solid much so I can't say, but my point is that if your app is rerendering unexpectedly that's because you haven't spend the time to think about the data flow around your app. It's possible, and not that hard even in a large app, to build things so that this doesn't happen. Signals sound like a way of avoiding updates, and if the experience of using them is elegant or if the performance is better that's awesome, but you definitely can build apps without them and never see the problem they solve.

I saw signals in Preact and I thought the same.

The article goes into exactly this.

> If you're delegating all of your coding skill to the framework and expecting it to just magically work no matter what dodgy code design you throw at it then you're going to build a shitty app.

Not to disagreed with you here, but there are many frameworks out there which either claiming themselves as "full-stack" or trying to be as full-stack as possible.

The developers who uses these frameworks might just expect "(delegating your code to the framework) is how it suppose to be used"(, while blaming people who write "raw" JavaScript code as "hacky").

This is a problem which will occur whenever you want to standardize the workflow as well as the knowledge base for your team. Some approach is discarded in this process and what's left in the end are often "common practices" which nobody has reason to reject. If the "common practices" is to let the framework to do it, then that will be that.