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.


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:


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

Get Web Workers now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.