In terms of the programming model, web workers are processes, not threads. They have no shared state, and use asynchronous message passing as the only inter-process communication - very much like Erlang. This makes them very simple, and fits in perfectly with JavaScript's existing asynchronous event-based model.

"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.)

>> "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)."

Yeah I much prefer that method personally.

Indeed; I kind of did the spec a disservice in calling it multithreading.

Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.