One of the fundamental features of JavaScript is that it is single-threaded: a browser
will never run two event handlers at the same time, and it will never trigger a timer
while an event handler is running, for example. Concurrent updates to application state
or to the document are simply not possible, and client-side programmers do not need to
think about, or even understand, concurrent programming. A corollary is that client-side
JavaScript functions must not run too long; otherwise, they will tie up the event loop
and the web browser will become unresponsive to user input. This is the reason that
fetch() is an asynchronous function, for example.
Web browsers very carefully relax the single-thread requirement with the Worker class:
instances of this class represent threads that run concurrently with the main thread and
the event loop. Workers live in a self-contained execution environment with a completely
independent global object and no access to the Window or Document objects. Workers can
communicate with the main thread only through asynchronous message passing. This means
that concurrent modifications of the DOM remain impossible, but it also means that you
can write long-running functions that do not stall the event loop and hang the browser.
Creating a new worker is not a heavyweight operation like opening a new browser window,
but workers are not flyweight “fibers” either, and it does not make sense to create new
workers to perform trivial operations. Complex web applications may find it useful to
create tens of workers, but it is unlikely that an application with hundreds or thousands
of workers would be practical.
Workers are useful when your application needs to perform computationally intensive tasks,
such as image processing. Using a worker moves tasks like this off the main thread so
that the browser does not become unresponsive. And workers also offer the possibility of
dividing the work among multiple threads. But workers are also useful when you have to
perform frequent moderately intensive computations. Suppose, for example, that you’re
implementing a simple in-browser code editor, and want to include syntax highlighting. To
get the highlighting right, you need to parse the code on every keystroke. But if you do
that on the main thread, it is likely that the parsing code will prevent the event
handlers that respond to the user’s key strokes from running promptly and the user’s
typing experience will be sluggish.
As with any threading API, there are two parts to the Worker API. The first is the Worker
object: this is what a worker looks like from the outside, to the thread that creates it.
The second is the WorkerGlobalScope: this is the global object for a new worker, and it
is what a worker thread looks like, on the inside, to itself.
The following sections cover Worker and WorkerGlobalScope and also explain the
message-passing API that allows workers to communicate with the main thread and each
other. The same communication API is used to exchange messages between a document and
<iframe> elements contained in the document, and this is covered in the following
sections as well.