Web Workers

Chapter 7. Web Workers Beyond the Browser: Node

The main motivation to implement Web Workers for NodeJS is to have a set of standard platform-independent concurrency APIs outside the browser. One powerful example is Peter Griess’ node-webworker module^[10], and you can find others on GitHub^[11].

These implementations let front-end web developers carry their knowledge of Web Workers technology beyond the browser. They also let developers avoid the NodeJS primitives for managing processes. The child_process^[12] provides a great deal of functionality, but is easily misinterpreted by developers who have not developed for a UNIX platform. The error reporting APIs in the Web Workers are also more full-featured and verbose than the one provided natively by child_process.

Using this module effectively requires understanding that Web Worker instances are relatively heavyweight and should be long-lived. Launching a Worker and maintaining its state requires a high per-instance memory cost. Therefore, it’s more efficient to pass messages to existing Workers to create tasks rather than creating a new Web Worker for each work item.

Processes

In the node-webworker module each worker implements in its own node process. This is done so we won’t need a separate thread (and V8 context) in the main node process. Each node process will be self-contained.

The main advantage of this approach include the following:

Performance

Modern operating systems are more likely to schedule different processes on different ...