You cannot generate 2000 updates a second if your computer cannot handle them.
Javascript runs a "main loop" that just executes "tasks". Tasks are chunks of synchronous code, and are not preemtible.
Let's say you have a "generator" task that generates 2_000 "update" tasks. The way this works is:
1. "generator" schedules 2_000 "update" tasks to run as soon as possible, and schedules another "generator" task for 1s from now.
2. The browser starts running "update" tasks one after the other as fast as it can.
3a. If the "update" tasks are all done 1s after the previous "generator" task, then the browser will run "generator" again.
3b. If they are not done, the browser will continue running "update" tasks and only invoke "generator" again _after_ it has finished with all the "update" tasks, be it 1 or 100 seconds after the previous "generator" task.
You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum culling). Games face an impossible amount of data, and schedule it. This is also true for native dev where you have priority dispatchers and threads. What React does is exciting because it schedules at the very root.
Games don't face an impossible amount of data. It might look like an impossible amount of data, but they play all sorts of cheats. In you have a crowd with 8k people, there might be 50 animations being computed and shared between the rest of the skeletons.
All members of the staff -- environment artists, character artists, level designers, animators, FX artists -- are all very technical and have the power and wisdom to use the framerate wisely.
I'm not even sure why you're bringing up frustum culling -- you're suggesting that we have too many objects to run the cull math on so we schedule across frames? But we don't; that results in visual popping. If culling is a bottleneck, we usually solve by broad-phase data structures like octrees, or ask the artists to condense multiple separate models into one so we have less objects to manage (another big cheat, artist labor).
Frustum culling is completely unrelated to scheduling. It’s just a technique for avoiding spending processing or rendering time on things that can’t be seen by the camera. It existed before games were multithreaded, during the time when they typically had a single main loop.
Games are not using complex scheduling and multithreading to achieve acceptable performance updating 2000 entities. You can achieve that easily on a single thread by laying your data out to take advantage of locality of reference and the CPU cache.
I put cannot in cursive because yes, you can schedule over the processing capacity limits. However, the CPU acts as a rate limiter in and of itself. If your CPU cannot process 2_000 updates per second, you will not be doing more than that, period. You can schedule 4_000 updates, but they will take 2s to process, no way around it. If you keep scheduling over the processing app capabilities, you will just run out of memory to hold the queue. Nobody is interested in doing that.
What games do is fundamentally different than what react is doing here. In games there are many places where you can trade off quality for speed (for instance frustrum culling). You can decide to compute less to fit within your computation time slice. Likewise, physics can take into account the update rate to adjust to the CPU/GPU's processing capability (i.e: you can use a delta_t in your computations to adjust for frame differences).
In the website there are some such opportunities (you could do it with animations for instance), but you cannot do it in general because most apps logic would not tolerate it (yeah sorry I dropped your request callback bad luck). For this reason I would be very surprised if React went that route.
No game engine does that and they don't face an "impossible" amount of data. A game designer may choose to spread work over several frames, but that is done on purpose by the developer.
And frustum culling has nothing to do with this nor it reduces any amount of updates.
Javascript runs a "main loop" that just executes "tasks". Tasks are chunks of synchronous code, and are not preemtible.
Let's say you have a "generator" task that generates 2_000 "update" tasks. The way this works is:
1. "generator" schedules 2_000 "update" tasks to run as soon as possible, and schedules another "generator" task for 1s from now.
2. The browser starts running "update" tasks one after the other as fast as it can.
3a. If the "update" tasks are all done 1s after the previous "generator" task, then the browser will run "generator" again.
3b. If they are not done, the browser will continue running "update" tasks and only invoke "generator" again _after_ it has finished with all the "update" tasks, be it 1 or 100 seconds after the previous "generator" task.