And this would be completely unnecessary if the JS code didn't run in the UI thread or in connection with the page (via user events). The reason to split up work and play with setTimeout() and friends is to avoid UI/page lock-ups or triggering the script max run timeout.
It's effectively co-operative multitasking where I trust the responsiveness of my browser to some random web coder.
Well actually, there may be other ways, for example it may be possible to detect conflicts!
Run the code in separate threads, and then at the end of the routine (or at synchronization points) check for a conflict. If there was a conflict, re-run the code in-order.
It's effectively co-operative multitasking where I trust the responsiveness of my browser to some random web coder.