mlsarecmg

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.

sounds like gpu accel is off. or extensions messing with the browser? mbp going to 1fps over a bit of webgl must have a cause.

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?

i can't say why webgl took over, as well as threejs, but i like how close to the metal they are. i would also much rather have a lower level representation underneath instead of starting outright with a markup language. i think that's why vrml eventually faded. i generally don't see why 3d should be represented in html.

as for react, it merely expresses threejs, and adds something which three doesn't have: self contained components that are now sharable. something like this: https://twitter.com/0xca0a/status/1394697847556149250 just didn't exist in the web previously.

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.

Threejs already has a webgpu renderer.

It has similar benefits as react-dom has for the dom. Less code, faster performance, less memory consumption, real interop with a growing eco system.

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.

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.

if you have a threejs app that pushes the limits, the react counterpart will merely do the same, only with less code. threejs renders exclusively.

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

this is a custom renderer. "react" does not know what a "div" is, this comes from "react-dom", that is why they have split these two packages apart.

but they also allow you to make your own renderer (https://github.com/facebook/react/tree/main/packages/react-r...) which then defines its own elements. you can try a mini threejs renderer here: https://codesandbox.io/s/reurope-reconciler-hd16y

i am sorry but there is a deep misconception here. of course you can update thousands of things, why wouldn't you.

try racing game for instance: https://twitter.com/0xca0a/status/1400164834243719173

or space game: https://twitter.com/0xca0a/status/1184586883520761856

you won't find react in the browsers perf readout except for short blips when the tree structure is changed. you do not update fast things with setState. since games are render-loop driven, you mutate, and that is also how r3f works.

as for react 18, yes, it works global. the entire component tree is virtual and can be prioritized. you could say, this thing back there is less important than physics driving my rocket, defer please. this will be an incredible tool for games going forward.

i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib.

some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.

no ref is used as an element in that code.

    const ref = useRef()
    useEffect(() => console.log(ref), [])
    return <div ref={ref} />

will return { current: [dom node] }

    const ref = useRef()
    useEffect(() => console.log(ref), [])
    return <mesh ref={ref} />

will return { current: [mesh node] }

we're running in circles unfortunately and i've explained where the test you're referring to comes from and what it meant. i've posted the real test and if you want, engage in it.

    async function test() {
      const chars = `!"§$%&/()=?*#<>-_.:,;+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz`
      const font = await new Promise((res) => new THREE.FontLoader().load("https://raw.githubusercontent.com/drcmda/scheduler-test/master/public/Inter%20UI_Bold.json", res))
      console.time("test")
      for (let i = 0; i < 510; i++) {
        new THREE.TextGeometry(chars[Math.floor(Math.random() * chars.length)], {
          font,
          size: 1,
          height: 0.5,
          curveSegments: 80,
          bevelEnabled: false,
        })
      }
      console.timeEnd("test")
    }

    test()

    // To really drive it home you'd have to repeat it every two seconds ...
    // setInterval(test, 2000)

how react 18 concurrency works exactly, i think that's not the right place to churn through it. the react team has published tons of reading material as well as public talks.

no special jsx pragma needed. this is actually just plain react, <div> <span> and so on come from react-dom, which defines these elements. other renderers define theirs. here's a mini custom renderer if this interests you: https://codesandbox.io/s/reurope-reconciler-hd16y

what you link there has more to do with react vs zustand.

if it interests you, read up on react 18 concurrency, this is the bit you are missing in this discussion.

r3f is a custom renderer, there is no difference in useRef between a div or a mesh, refs give you the underlying object. lowercase elements are native elements (div, span, mesh, view, box), they are defined by the renderer. uppercase is for components.

there were multiple versions of that test, the fist had nothing to do with the subject matter, the ones that people refer to (spinning cubes) had an artificial delay that was added to simulate cpu stress.

this is how refs work. it's the same with a div. the ref will be filled in useEffect, not before.

null! is a common typescript thing, it is a semantic guarantee that the ref is static and hence will be available. this saves you the if (ref.current) { ... } check.

you want your view to do something, to participate in the render loop, to animate, user interaction etc. look at the example on the main page: https://github.com/pmndrs/react-three-fiber#what-does-it-loo...

it does not take a dom-equivalent tree, it just expresses the same code you would write out imperatively in a declarative way. threejs is a nested graph after all.

hard to read through all that tbh. i mostly do not understand what you are talking about when threejs is clearly a tree that react expresses with complete ease. groups in groups with meshes, which have materials, etc. it seems to me you have not worked with threejs before. r3f just expresses threejs, in the same exact same shape you'd have in an imperative app.

there are dozens, hundreds of demos now that are testament to this approach: https://docs.pmnd.rs/react-three-fiber/getting-started/examp... this is slowly becoming the norm of how you write a 3d app or game.

r3f does not introduce overhead. the readme text explains it all https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf...

as absurd as it may seem to you, this is a react feature. the upcoming react 18 release is pretty much based on concurrency.

this is the test you are referring to: https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf...

the github repo now contains a vanilla test that you can run

you can't express a 3d scene with markup alone, that is why VRML didn't succeed. the JSX you see just masks function calls, it is not XML or HTML, but the true power is in components and hooks (useFrame, etc). a r3f component is self-contained, it will even subscribe to the render-loop. click into these two examples to see the difference: https://twitter.com/0xca0a/status/1426924274527477764

react has little to do with html. it just calls functions, what you see in react-dom isn't html either, these are nested document.createElement(...) calls. this can be configured for any platform, web, native or otherwise, so <mesh/> in this case is just new THREE.Mesh(). in react terms it's called a custom renderer.

the other thing you say, that react is bad for animations — r3f operates outside of react, there is no overhead, it actually quite easily outperforms threejs. but there are many other benefits, it will usually save you lots of code, and it can be more memory efficient, see this thread: https://twitter.com/0xca0a/status/1426924274527477764

the biggest advantage is the component model, because it allows for a true eco system, something that threejs does not otherwise have due to the lack of a common ground. and interop. every react library can now act on meshes and materials.

the scene is a real graph. the difference between imperative and declarative becomes more evident with examples, for instance three: https://codesandbox.io/s/basic-threejs-example-with-re-use-d... and react: https://codesandbox.io/s/basic-react-example-with-re-use-e2z...

declaring the graph in combination with hooks is how you form self-reliant components.

as for leaf nodes, if they pre-exist they are declared as props, but you can also declare them. they are part of the graph. the only difference is that they don't go into "children".

It is a using custom renderer indeed: https://github.com/pmndrs/react-three-fiber it doesn't wrap Threejs, just expresses it via JSX similar to how react-dom expresses the dom.