React acknowledges that nothing can ever be purely declarative, it allows you to declare a view while giving you an outlet for imperative computations and side-effects (hooks). There is no contradiction in that.
In Fiber to animate is to use useFrame, which happens to be outside of React and bears no extra cost or overhead, nor does it conflict with reactive prop updates. useFrame allows any individual component to tie its mutations into the render loop.
The reactivity debate is next to irrelevant in WebGL because that is a loop driven system, it is not event-driven like the DOM. If you doubt that observe Svelte/Threlte, which can update the view directly, yet relies on useFrame modeled after Fibers. That is because you need deltas (to be refresh-rate independent), flags (needsUpdate), imperative functions (updateProjectionMatrix etc), it is never just a prop update.
That said, i don't know much about React-Pixi/Konva and so on, and if these do not have a loop outlet then yes i agree. But the whole premise of that article just falls flat.
threejs has no problem rendering hundreds of thousands of objects, so react doesn't have a problem either because its baseline is threejs, it does not introduce overhead or a performance penalty. These components render in a regular RAF loop, react is not involved at all unless you are mounting/unmounting objects, and this is where it can actually be faster.
React is not based on the dom, R3f merely expresses regular threejs which works as an object graph. Three is the usual choice for 3D on the web, if you use it once you'll see that it is also quite natural. There is no conflict between the two and react certainly doesn't change any rules or apis, it just builds a graph, which you would normally form imperatively.
React is inspired by the DOM and they split it before 1.0 IIRC, but that misses the forest for the trees. The main issue I had is that React, Three.js, and R3F are all hierarchical/tree-like (what you and Three.js are calling a graph). You can technically yes, build 3D scenes, but anything non-trivial will be very awkward.
Let's say you're building a game where you want a sphere to stick to whatever player you throw it at. How would you do that with a scene graph/OOP model? It'd be awkward, removing objects from one parent and adding them to another. Even more awkward if it's a complex object and you only want a part of that complex object to stick to the player. ECS + a constraint or physics system does a decent job (not perfect) of handling this in a relatively elegant and performant way.
I've used Three.js enough--built my portfolio[1] out of it, and then switched to Babylon when I realized how little I liked Three.js. For the record, I also dislike Babylon.
i have yet to encounter something that shouldn't be expressed as a graph. three, babylon, ogl, blender, gltf, cad, games, they're all scene aligned. that doesn't seem to be a conflict since you still use shaders, physics, ecs and so on.
could you go more into detail what you mean when you say "anything non trivial"? is there a real example of something that would not be possible to create in, say, threejs?
You are arguing against threejs not react. R3f reconciles threejs in the exact way it's getting used, a graph. This ofc is also how blender gltf et al work. If you make a webgl app on the web you most likely use three and all react does is make that a little ordered with some additional benefits when it comes to performance, memory and interop.
there are many large scale apps built with it these days. it was initially made for complex use cases, to bring order into the scene graph, and of course to optimize raw rendering performance: https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf...
In Fiber to animate is to use useFrame, which happens to be outside of React and bears no extra cost or overhead, nor does it conflict with reactive prop updates. useFrame allows any individual component to tie its mutations into the render loop.
The reactivity debate is next to irrelevant in WebGL because that is a loop driven system, it is not event-driven like the DOM. If you doubt that observe Svelte/Threlte, which can update the view directly, yet relies on useFrame modeled after Fibers. That is because you need deltas (to be refresh-rate independent), flags (needsUpdate), imperative functions (updateProjectionMatrix etc), it is never just a prop update.
That said, i don't know much about React-Pixi/Konva and so on, and if these do not have a loop outlet then yes i agree. But the whole premise of that article just falls flat.