I'm web dev recently introduced to game dev. I'm curious why the two worlds have such different approaches. Another example is ECS being more prevalent in games than in web apps.
Web page: Wait for data from server, update page to match, this usually happens at most every few seconds. (or if it's server based) Fetch data, format into html, set to browser
Game: For 10s to 1000s of objects, run some code for each one at 60 frames a second. That code is usually one or more finite state machines and/or co-routines per object (or some hacked together code that effective does the same). This code updates a bunch of state for each object, and then other code displays the current state.
They're doing different things so they take different approaches.
I think react is not as immediate-mode as what you see in many immediate UI libs. In particular the canonical "let buttonPressed = drawButton("OK")", where your button state/press is actually reported back. In React events on your components have to flow back through some strategy.
This is either a nit or a completely fundamental difference that entirely changes the ask.
Immediate mode isn't _just_ about repeating the UI every frame
That's an interesting take I agree with. It's kinda interesting how lots of technologies are converging from totally different directions.
IMO there is also a few parallels between centralised event stores like Flux/Redux and ECS. Sure the data is organised completely differently (perhaps Flux can learn from ECS here) and updated differently (perhaps ECS can learn from Flux here) but the concept of centralising state is similar IMO.
