3 ms·

It's great... except that it turns out to be a performance pitfall if the state needs to be frequently updated. The React Three Fiber docs mention this here: h

It's great... except that it turns out to be a performance pitfall if the state needs to be frequently updated. The React Three Fiber docs mention this here: https://r3f.docs.pmnd.rs/advanced/pitfalls#avoid-setstate-in-loops https://r3f.docs.pmnd.rs/advanced/pitfalls#avoid-setstate-in... To fix this, they suggest using useRef and manually updating the object. But then your code ends up just as complicated, if not more so, than if you had just stuck with vanilla three.js.

rafram 1y ago
Yeah, I can only imagine what removing an element from the middle of a thousand-element array of entities would do. This has always been a performance weak point for React, but React trees aren’t typically rebuilt from the root 60 times a second. With this, they are.
afavour 1y ago
Sadly I’ve lost the URL but there was once a great comparison of Svelte vs React for this exact functionality. The performance was orders of magnitude better IIRC. React code looks great, the dev experience is fantastic. But user experience sometimes less so. Hooks kind of hide what’s going on.
- 90s_dev 1y ago
  I am exploring this area in a pet project, because some part of me has always been absolutely confident that we can do better than both vdom and custom compilers. So far, I have made really exciting progress, though it has never been more than 2-3 levels deep, for example a basic todo list, so it's hard to say that it will solve the main difficulty elegantly, but so far it seems to do so in principle, and I hope soon to come up with a use-case that allows me to finally create the deepRef function that I can just tell is the final piece of the puzzle.
baxuz 1y ago
The only way to have performant rendering in a React app is to eject from React's rendering pipeline — that is, to not use it at all. State should basically only be used as "keyframes"
klysm 1y ago
I like react because it gives you escape hatches like this. You can take a range of approaches, starting with simple and declarative, only moving to gross and performant if required.

rafram 1y ago

Yeah, I can only imagine what removing an element from the middle of a thousand-element array of entities would do. This has always been a performance weak point for React, but React trees aren’t typically rebuilt from the root 60 times a second. With this, they are.

afavour 1y ago

Sadly I’ve lost the URL but there was once a great comparison of Svelte vs React for this exact functionality. The performance was orders of magnitude better IIRC. React code looks great, the dev experience is fantastic. But user experience sometimes less so. Hooks kind of hide what’s going on.

90s_dev 1y ago
I am exploring this area in a pet project, because some part of me has always been absolutely confident that we can do better than both vdom and custom compilers. So far, I have made really exciting progress, though it has never been more than 2-3 levels deep, for example a basic todo list, so it's hard to say that it will solve the main difficulty elegantly, but so far it seems to do so in principle, and I hope soon to come up with a use-case that allows me to finally create the deepRef function that I can just tell is the final piece of the puzzle.

baxuz 1y ago

The only way to have performant rendering in a React app is to eject from React's rendering pipeline — that is, to not use it at all. State should basically only be used as "keyframes"

klysm 1y ago

I like react because it gives you escape hatches like this. You can take a range of approaches, starting with simple and declarative, only moving to gross and performant if required.