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.

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.

But you can actually see this dichotomy in template libraries, they usually have constructs making them fully Turing-complete (loops, conditionals, etc).

https://threlte.xyz/

When all you know is React, everything gets viewed through that limited lens.

React code looks great, the dev experience is fantastic. But user experience sometimes less so. Hooks kind of hide what’s going on.

State should basically only be used as "keyframes"

GP - are we misunderstanding something here?