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.
If you want to use this today, you'll still need to sniff for it and call setTimeout if it's not available. So unless those 10ms are really important to what you're doing, this will just cost you more work.
That's the problem with cool new browser features. It just takes forever before they trickle down to enough of your users that it makes sense to use them.
Sometimes it's worth the wait. I can remember thinking all of the above about xmlHttpRequest and how lame it was that I'd still need to switch on it and have Netscape continue to use IFrames to do asynch communication back when IE5 came out.
I suspected so, but I thought I'd throw that in anyway (who knows - maybe it would matter on IE). I prefer not setting variables if they're unneeded regardless.
It's effectively co-operative multitasking where I trust the responsiveness of my browser to some random web coder.