If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane.
It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.
"What operations 'block' in js?"
Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0).
(Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
Yeah I much prefer that method personally.
Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.
http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre...
'''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''
Moz: https://developer.mozilla.org/En/Using_web_workers WHATWG: http://www.whatwg.org/specs/web-workers/current-work/