3 ms·
> 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 t
by tomgp 4y ago
> 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)
- h0l0cube 4y ago> 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.
- onion2k 4y agoI 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.
- bernawil 4y ago> 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.
- tomgp 4y agoYeah, 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.