Web worker

3. 10.3 APIs available to workers 1. 10.3.1 Importing scripts and libraries Web Workers API/Using web workers or fetch (with no such restrictions). Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa).") This specification defines an API for running scripts in the background independently of any user interface scripts. This allows for long-running scripts that are not interrupted by scripts that respond to clicks or other user interactions, and allows long tasks to be executed without yielding to keep the page responsive. Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image. The examples below show some appropriate uses of workers. Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost. There are a variety of uses that workers can be put to. The following subsections show various examples of this use. The simplest use of workers is for performing a computationally expensive task without interrupting the user interface. In this example, the main document spawns a worker to (naïvely) compute prime numbers, and progressively displays the most recently found prime number. The Worker() constructor call creates a worker and returns a Worker object representing that worker, which is used to communicate with the worker. That object's onmessage event handler allows the code to receive messages from the worker. const url = document.querySelector(" image-url"); const filter = document.querySelector(" filter"); const output = document.querySelector(" output"); This second example extends the first one by changing two things: first, messages are received using addEventListener() instead of an event handler IDL attribute , and second, a message is sent to the worker, causing the worker to send another message in return. Received messages are again displayed in a log. In this example, multiple windows (viewers) can be opened that are all viewing the same map. All the windows share the same map information, with a single worker coordinating all the viewers. Each viewer can move around independently, but if they set any data on the map, all the viewers are updated. Open a new viewer Each viewer opens in a new window. You can have as many viewers as you like, they all view the same data. There are several key things worth noting about the way the viewer is written. Registering event listeners in this way also allows you to unregister specific listeners when you are done with them, as is done with the configure() method in this example. A later version of the API, though, might want to offload all the crypto work onto subworkers. This could be done as follows: Notice how the users of the API don't have to even know that this is happening — the API hasn't changed; the library can delegate to subworkers without changing its API, even though it is accepting data using message channels. Dedicated workers use MessagePort objects behind the scenes, and thus support all the same features, such as sending structured data, transferring binary data, and transferring other ports.