What solution would you recommend? I have given this a lot of thought and have a few ideas. Is there a venue for discussing the problem and suggesting possib

What solution would you recommend? I have given this a lot of thought and have a few ideas. Is there a venue for discussing the problem and suggesting possible solutions? In lieu of a decent forum. I'll drop my thoughts here. I have felt that the fundamental problem with JavaScript is that it cannot pre-empt. Even with its concurrency of web workers the primary example they give shows the flaw inherent in their solution http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#a-background-number-crunching-worker http://www.whatwg.org/specs/web-apps/current-work/multipage/... As a challenge, try and write a version of this worker that the owner page can switch between two number sequence algorithms(prime / Fibonacci for example). The only way you can do this is to rework the program until it's back to being a program beholden to events. You could solve most of this with a pre-emption mechanism. Allow an additional way to respond to certain inputs by registering an interrupt instead of listening to an event. function myInterrupt(preEmptedState) { interruptCounter+=1; //do something useful here setExecutionState(preEmptedState); //switch execution context back to pre-empted thread. } The parameter to the interrupt function is the execution state of the thread that was pre-empted. This can be restarted at the end of the interrupt, stored for continuation at a later time (enabling blocking), or abandoned (effectively terminating the thread). What this would need is: An execution state object, possibly an opaque object. addXXXInterruptHandler(interruptHandler) ;; XXX= Timer/Message/Input/etc. setExecutionState(newState) ;; this function would not return, it would continue the new state. createExecutionState(main) ;; generate a new execution state object ready to run the function main triggerInterrupt(interruptType) ;; Allow a tread to trigger an interrupt upon itself. If interrupts themselves are simply the running of a new execution state then TriggerInterrupt is just a special case of setInterruptState. Having this as a core would allow a huge number of higher level constructs that would enable blocking functions, and sane interactions with running processes like web workers. Yes, you would introduce the possibility of race conditions etc. but only if you actually used the new functionality. If you chose to leave it alone you would be on the old single eventy thready system that we know and hate. It would also mean you could have someone write var x=0; while(x<10) {} without it killing all scripts.