3 ms·

Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetc

Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. 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. I think this highlights part of the problem with React and most other frameworks - people expect too much from them. 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. You have to remember that you still have to think things through, use your skills as a dev, understand what's happening and why. That is always going to be true. You're always going to have to put the work in. At the beginning of the article the author says they feel trapped by React because their previous, current, and next jobs are all going to be React based. That isn't true if they choose to put effort into learning other technologies and seeking roles that use them. If you work hard you find options open to you. Heck, they could move out of web and start writing completely different code that isn't even JS if they felt they wanted to. No one is being held hostage by React. You are only held hostage by your own fear of doing something hard. Feeling like you have to stick with React is a state of mind - you can change that with enough effort.

azangru 4y ago
> 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.
- k__ 4y ago
  I saw signals in Preact and I thought the same.
  - berkes 4y ago
    The article goes into exactly this.
- onion2k 4y ago
  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.
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 ago
  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.
nirui 4y ago
> 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.

azangru 4y ago

> 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.

k__ 4y ago
I saw signals in Preact and I thought the same.
- berkes 4y ago
  The article goes into exactly this.
onion2k 4y ago
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.

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 ago
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.

nirui 4y ago

> 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.