3 ms·

React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not en

React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though. My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard to know what parts of your code are going to run, and when. I'm sure someone will argue, just refactor your components to be small, avoid useEffect as much as possible. I try! But I can't control for other engineers. And in my experience, nobody wants to refactor large components, because they're too hard to reason about! And the automated IDE tools aren't really built well to handle refactoring these things, so either you ask AI to do it or it's kind of clunky by-hand. (WebStorm is better than VSCode at this, but they're both not great) The other big problem with it is it's just not very efficient. I don't know why people think the virtual DOM is a performance boost. It's a performance hack to get around this being a really inefficient model. Yes, I know computers are fast, but they'd be a lot faster if we were writing with better abstractions..

Izkata 8mo ago
> so either you ask AI to do it I dunno, AI tools love adding not only useEffect but also unnecessary useMemo. > I don't know why people think the virtual DOM is a performance boost. It was advertised as one of the advantages when React was new, due to the diffing browsers would only need to render the parts that changed instead of shoving a whole subtree into the page and the having to do all of it (because remember this came out in the era of jquery and mustachejs generating strings of HTML from templates instead of targeted updates).
- MrJohz 8mo ago
  Patching the DOM existed long before React, that wasn't a new technique. IIRC, the idea was more that the VDOM helped by making batching easier and reducing layout thrashing, where you write to the DOM (scheduling an asynchronous layout update), read from the DOM (forcing that thenlayout update to be executed synchronously now). That said, none of that is specific to the VDOM, and I think a lot of the impression that "VDOM = go fast" comes from very early marketing that was later removed. I think also people understand that the VDOM is a lightweight, quick-to-generate version of the DOM, and then assume that the VDOM therefore makes things fast, but forget about (or don't understand) the patching part of React, which is also necessary if you've got a VDOM and which is slow.
nosefurhairdo 8mo ago
Re: excessive useEffects, this article from React docs is great: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/ https://react-scan.com/ Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.
- overgard 8mo ago
  Definitely good points, thanks for the links. While I try to practice all of these, I think what tends to happen on large codebases is just a bit of entropy. Like, these are all good practices that are either a little obscure or a little less convenient, and so they don't tend to be used. I dunno, it's kind of like in OO code when people just keep letting classes grow. I think the subtle difference though is most IDE's are quite a bit better at refactoring classes than components though. Hopefully that changes. (I know you can use AI for refactoring, but I prefer doing it mechanically.. more predictable and also just not burning tokens)

Izkata 8mo ago

> so either you ask AI to do it I dunno, AI tools love adding not only useEffect but also unnecessary useMemo. > I don't know why people think the virtual DOM is a performance boost. It was advertised as one of the advantages when React was new, due to the diffing browsers would only need to render the parts that changed instead of shoving a whole subtree into the page and the having to do all of it (because remember this came out in the era of jquery and mustachejs generating strings of HTML from templates instead of targeted updates).

MrJohz 8mo ago
Patching the DOM existed long before React, that wasn't a new technique. IIRC, the idea was more that the VDOM helped by making batching easier and reducing layout thrashing, where you write to the DOM (scheduling an asynchronous layout update), read from the DOM (forcing that thenlayout update to be executed synchronously now). That said, none of that is specific to the VDOM, and I think a lot of the impression that "VDOM = go fast" comes from very early marketing that was later removed. I think also people understand that the VDOM is a lightweight, quick-to-generate version of the DOM, and then assume that the VDOM therefore makes things fast, but forget about (or don't understand) the patching part of React, which is also necessary if you've got a VDOM and which is slow.

nosefurhairdo 8mo ago

Re: excessive useEffects, this article from React docs is great: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/ https://react-scan.com/ Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.

overgard 8mo ago
Definitely good points, thanks for the links. While I try to practice all of these, I think what tends to happen on large codebases is just a bit of entropy. Like, these are all good practices that are either a little obscure or a little less convenient, and so they don't tend to be used. I dunno, it's kind of like in OO code when people just keep letting classes grow. I think the subtle difference though is most IDE's are quite a bit better at refactoring classes than components though. Hopefully that changes. (I know you can use AI for refactoring, but I prefer doing it mechanically.. more predictable and also just not burning tokens)