In certain instances, we may earn revenue when a reader makes a purchase or completes a form through our pages or on a partner’s website. We adhere to a strict What Does Web Workers Mean?
Web workers is a new application programming interface being developed for HTML5 that allows software processes to run in background threads. Web workers are created on the client. They run parallel to, and are unusually created by, the processes responsible for the user interface (UI). Once created, Web workers can communicate with their parent creator by sending messages to specified event handlers of the UI defined by the parent.
Web workers are technically known as the Web workers API. Most major browsers (except Internet Explorer 9) support the functionality.
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.
