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