The examples here
https://threejs.org/examples/#webgl_animation_keyframes
seem to work great on my phone...
Since they bring their own reconcile(a, b, diff) function to React, these libs can turn:
const world = new World()
const player = new Player()
world.add(player)
// somehow wire up the code to keep
// player.pos updated
const [x, setX] = useState(0)
return <World>
<Player x={x} />
</World>
Just like how it helps you sync your data model to underlying stateful DOM nodes; the idea can be applied on top of any stateful system.
I wonder if there’s any research (PL or maybe even more philosophical) on whether declarative approaches can logically cover all imperative use cases.
Basically: is there something special about “verbs” (imperative) that let you do things that “nouns” (declarative) cannot, at least within reasonable verbosity constraints?
SwiftUI has failed pretty much all of those for me.
In react-pixi / react-three, you have your declarative component tree alongside a `useTick`/`useFrame` function that you can use to do more surgical work, and it works well together. Each component can tap into the tick to update itself.
const Enemy = ({ initalPos, size }) => {
const [pos, setPos] = useState(initialPos)
useTick(dt => {
setPos(/* Move in a circle */)
})
return <Sprite
src="/enemy.png"
size={size}
pos={pos}
/>
}
Before that, I'd tried modeling games in Elm and then using its port system to send the game state to JS which then updates the pixi/three world. But it's exactly this updateWorld(oldWorld, newState) that's hard to write, yet that's what these libs do for you.
For instance, Solid also supports custom JSX renderer, but doesn’t use a VDOM to achieve that.
I find it helpful to think of JSX as analogous to a macro (in the lispy sense of the term), except that its syntax and implementation are decoupled. Most compiler tooling assumes the implementation maps to a function call, but even that isn’t strictly required (and again, Solid is a counter example).
When all you know is React, everything gets viewed through that limited lens.
The point is about the declarative abstraction and how it's useful for people who don't know what "React Three" might entail, not to enumerate all the frameworks that have it under a submission about "React Three Ecosystem".
Taking a quick look at [the docs](https://r3f.docs.pmnd.rs/getting-started/introduction) linked above, I see the use of Canvas. Fair enough.
I start using X3D at work in order to enable some cool functionality showing steps to build an assembly in 3D, and it's actually insane how high the performance is. It's all HTML components, so I wrote a super thin React wrapper (essentially the scene needs to be manually loaded once, that's about all) and have been cruising with that.
Effortless to fly, rotate, hide or highlight parts, decompose things into x3d assets, and so on.
It might have issues somewhere, I haven't widely tested browser compat or anything, but it's curious to me how little I see it versus how much I see ThreeJS when it seems that X3D is the more capable platform.
tlarkworthy•5h ago
[1] https://threejs.org/
jasonjmcghee•3h ago
I understand why people like the declarative nature of react three fiber, but it's quite unfortunate that it requires something like code sandbox to allow modification / working with it on the web- but that's by nature due to being react.
Vanilla three.js can be written surprisingly similarly, if you are disciplined about breaking things up into functions/components. And no react necessary / can embed a code editor and allow direct modification.
eyelidlessness•2h ago
It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.
mikebelanger•1h ago
That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction.
But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways
ttfkam•2h ago
https://threlte.xyz/