Web Workers

Techopedia explains Web Workers

The Web workers API specifies two kinds of workers - the dedicated worker and the shared worker. The dedicated worker is the simplest; it is designed to perform and complete some sort of task. An example might be a clock that is updated on a user screen. The dedicated task fires in the background, does the clock update and ends.

A shared worker is more complicated in that it has the ability to communicate by replying back via an event handler function. An example might be the validation of user address and phone info on a registration screen. Each piece of data must be verified. When the results are complete, they are handed off to the page, so that it knows that all the user's data is valid and it can continue with the registration process.

Web workers have a lot of promise for improving the user experience of Web-based programs. The speed with which a browser screen can be updated is increased significantly because there are now multiple processes doing the updating.

However, there are still some things that need to be worked out. First, thread safety and concurrency can be a problem. Remember, these are client-side processes that are actually using back-end Web servers to call OS-level threads on the client. By definition, there is not much standardization here.

Secondly, a Web worker is passed a uniform resourse identifier (URI) of the script to execute when it is created. These URIs should pass the same-origin policy that has been developed in response to client-side security concerns, although there is currently some disagreement among browser vendors as to whether these URIs need to pass this same sniff test.

Finally, packets of info passed back for shared Web workers must be serialized, which can be a slow process. At some point, the efficiency of using a Web worker must be offset against the processing time of serializing.