I have a dillema, we are on the beginning of the big project and we need to decide to pick ThreeJS (class approach) or R3F. That’s gonna be app where user can customise clothes. Probably, there is a chance that app is gonna be implemented as a iframe on different site. Our devs know react but in the future we want to hire new devs with a knowledge of threeJS and here R3F is additional requirement.
Is there any edge cases in R3F? Something that can be done in three js but not in R3F?
Then go with react-three-fiber - since you’ve mentioned you have devs experienced in react, the reasons behind going with r3f instead of vanilla three.js are quite the same as going with react instead of vanilla javascript + HTML.
Looking at dev community of three.js - since people learn from similar resources - most commercially-active three.js devs will also be familiar with r3f, so this shouldn’t be much of an issue.
The advantage of going with r3f is that you don’t really have to use react-syntax / state flow all the time. If you feel better doing imperative code, you can do that in react-three-fiber as well, just put vanilla three.js code in useMemo / useRef / useEffect and you’re good to go. It doesn’t work the other way - so going with vanilla you are losing access to drei, to react state flow, simple event handling, and quite a few other things that r3f tends to make easier. Then, if something is not ready made in r3f, you can always just code it in vanilla three.js as a custom class, and add to your r3f project (r3f is three.js, just written differently, so you are not going to get compatibility issues trying to add vanilla three code.)
fiber is threejs, anything that three can do so can fiber. but there are many things fiber can do that three can’t because of the differences between declarative functional programming and oop. for instance composition. it has developed an eco system because of it. the showcase demonstrates what a difference it makes React Three Fiber Documentation otherwise everything mj said.