JavaScript Web Workers Visualized - Crash Course 2026

This section is going to be exciting. It's going to set you up with the foundational knowledge to start coding up web workers.

In the JavaScript runtime environment, which operates on a single-threaded model, threads refer to lightweight, concurrent execution paths typically found in multi-threaded languages like Java or C++, where multiple threads share memory and run tasks simultaneously on separate OS-level threads to boost performance. JavaScript's engine (e.g., V8 in browsers or Node.js) executes code synchronously on one main thread via a single call stack, processing one task at a time in LIFO order, avoiding complexities like race conditions or deadlocks. However, the broader runtime (browser Web APIs or Node's libuv) simulates concurrency by offloading blocking operations (e.g., timers, I/O) to background threads or pools, with results queued via the event loop for non-blocking execution on the main thread.

In JavaScript’s single-threaded runtime model, think of your computer’s CPU cores as the physical engines — actual pieces of hardware doing the work. A thread, on the other hand, is like a train running on those tracks — it’s not physical, but rather a path of execution that the engine follows. JavaScript uses just one main thread, meaning only one “train” runs tasks like executing code, handling events, and updating the UI at a time. Even though modern CPUs have multiple cores (so they could run several trains in parallel), JavaScript’s design keeps things simple and predictable by sticking to one main track — and when it needs help (like for background tasks), it offloads them to separate worker threads without breaking the single-thread illusion.

In this lecture you'll be introduced to "concurrency". Think of JavaScript as a chef who works alone in a kitchen — only one pair of hands, so they can cook one dish at a time (that’s the single-threaded model). But this chef is smart: instead of waiting for water to boil or bread to bake, they set timers and move on to chop vegetables or stir soup. When the timer buzzes, they return to that dish. That’s how JavaScript handles concurrency — the event loop acts like the chef’s assistant, keeping track of timers, tasks, and callbacks so everything gets done efficiently without the chef ever needing extra hands.

JavaScript lacks traditional concurrency because it's strictly single-threaded at its core, running one operation at a time on the main thread—unlike Go, Erlang, or Java, which natively juggle multiple threads or processes with sync tools like mutexes or channels. Instead, it fakes concurrency via the event loop, which handles async I/O non-blockingly by queuing callbacks for tasks like fetches or timers, creating a multitasking illusion; yet a single blocking loop still freezes the whole show until done.

JavaScript runs in a single-threaded model within its runtime environment, meaning the main thread processes one task at a time via a call stack—like a solo chef juggling orders on a single grill, where a heavy recipe (say, crunching big data) blocks everything else, freezing your UI. Enter Web Workers: they're like hiring backup chefs in separate kitchens (background threads) to cook heavy tasks simultaneously without hogging the main grill.

Parallelism here means multiple threads running at the same time on different CPU cores—those workers chomp computations (e.g., image filters or chess AI moves) independently, chatting via postMessage like walkie-talkies, keeping your app snappy.

JavaScript runs on a single main thread in browsers, juggling tasks via an event loop—like a busy chef handling orders one by one without freezing the kitchen (UI). Use Web Workers to offload CPU-heavy tasks (e.g., crunching large datasets, image processing, or complex chess move calculations) to a background thread, keeping the UI responsive; post results back via messages when done. Don't use them for network requests (like fetch or WebSockets), as these are naturally async on the main thread via promises—they don't hog CPU cycles and yield control automatically, adding Workers would just mean needless message-passing overhead without benefits.

I almost can't believe you have finished this entire section, so quickly. WELL DONE. In this lecture we will revisit our starting code example and you'll be amazed at how far you've come.

A web worker, as you learned in the last section, allows you to spin up a new JS runtime and run code off another separate main thread. This lecture is a quick recap before we jump into a coding editor.

For the first time in this crash course, we'll set up a Web Worker by using the default Worker API. I'll also show you that when you create a worker, there is internal memory created by the host environment to set up its entire environment.

“Web Workers” and “Worker Threads” are two different APIs that both give JavaScript extra threads, but in different runtimes and with slightly different capabilities.

Where each one lives

• Web workers: Run in browsers, giving you background threads separate from the main UI thread, with no direct DOM access and communication via postMessage.

• Worker threads: Run in Node.js on the server, giving Node a way to execute JS in parallel without using multiple OS processes, also communicating via messages.

Conceptually, both are about offloading CPU‑heavy or blocking work to other threads so the main thread (UI in the browser, event loop in Node) stays responsive. But just understand that technically, they target different environments (frontend vs backend), so available APIs inside the worker differ (DOM vs Node core modules, filesystem, etc.).

Web Workers run JavaScript code in isolated background threads separate from the main browser thread, so they don't share the same global or local variables, memory scope, or execution context. Any data exchange must occur explicitly via messaging (which yes, we will get into in the next lecture). This design keeps the UI responsive while avoiding race conditions, though it adds serialization overhead for frequent communication.

The line const worker = new Worker('worker.js') instructs the browser to create a new Web Worker instance by fetching, parsing, and executing the script at 'worker.js' in a fully isolated background thread with its own global scope and event loop, separate from the main thread. This assigns a Worker object to the const worker variable, enabling the main thread to communicate via postMessage(), listen for message events, or terminate it with worker.terminate(), all while preventing shared memory access to maintain UI responsiveness and thread safety.

In this lecture, we'll dive into sending messages from the main thread to a Web Worker using the postMessage method, a key mechanism for thread-safe communication in JavaScript. After creating a Worker instance with new Worker('worker.js'), you can pass data—such as strings, objects, or arrays—directly to the worker by calling worker.postMessage(data), where data is any structured-cloneable value that gets serialized and delivered asynchronously. On the worker side, this triggers the onmessage event (or addEventListener('message', ...)), allowing the worker to receive, process, and optionally respond back via its own postMessage call, enabling seamless coordination for tasks like heavy computations without blocking the UI.

In this lecture let's continue looking at our simple example. I want to show you first hand that if our worker performs a heavy task, like counting to 10bn, it will not block the main thread. This is the power of JavaScript's web workers.

Closing a web worker involves calling the terminate() method on the Worker object from the main thread, which immediately stops the worker's execution, discards its event loop tasks, and releases associated resources without allowing cleanup or completion of ongoing operations—potentially leading to memory leaks if not handled carefully. Inside the worker itself, self.close() can be used for a more graceful shutdown, canceling pending tasks while permitting current synchronous code to finish. Per the Web Workers spec, browsers may also implicitly terminate workers when the parent document unloads (e.g., page navigation), though behavior varies by implementation, so explicit termination is recommended for reliability.

In the last lecture we acccessed both the close() method and terminate() method.

But did you notice that I only accessed close() on the worker, and terminate on the main thread? I'm sure you did, because you are a very astute student.

Well, let me explain. The self.close()—called from inside the worker script—gracefully shuts down the worker by completing the current synchronous task and any queued microtasks before canceling all pending macrotasks (like timers or postMessage), preserving some integrity without abrupt interruption. In contrast, worker.terminate()—invoked from the main thread—forces an immediate kill of the worker, aborting execution instantly, discarding every pending task, and freeing resources with zero cleanup opportunity. This design ensures workers can self-exit controllably while the main thread retains authority for emergency stops on hung or rogue processes.

Because this course is to awesome, I am going to teach you how to set up a worker thread. In other words, we are moving away from a browser context and we will now execute JS code in workers, from a server perspective.

Buckle up, you're in a for a great ride.

A quick word on what we're doing next.

I want you to see that the concepts you are learning in this course are REAL and practical. Let's view the CPU utilization when running intensive Node.js tasks by using performance.now() to time a heavy computational loop (50 × 1e9 iterations), showing how the main thread blocks and spikes CPU usage to >50% on a single core. This highlights Node's single-threaded nature.

Importing Worker and parentPort from Node.js's worker_threads module follows standard procedulre. In the main thread, you use Worker to spawn new threads (new Worker('./worker.js')). In the worker thread, parentPort becomes available as a MessagePort for bidirectional communication back to the parent (parentPort.on('message', ...) and parentPort.postMessage()), while Worker lets workers create their own child workers. This selective availability - Worker everywhere, parentPort only inside workers - is done for a reason. It enforces the parent-child hierarchy cleanly when working with worker threads inside of a server.

You might be wondering why we can access the Worker object in the browser directly, but when it comes to Node.js, we have to first import the Worker class from the worker_threads module? Great question.

In this lecture we are going to up the ante. We are going to get more complex by allowing the developer to choose how many workers they wish to complete the heavy task. This is the power of JavaScript's web workers - they allow your application to offload heavy tasks to one (or more) CPU core's, in a totally different thread separate from the main thread.

We are nearly done, my dear student. In this lecture we will finish off our code in the main thread and send tasks to each worker.

In this final lecture we'll see our code in action.

This is the entire point of this Web Workers crash course - to show you visually how web workers work, and how they can be used to increase performance of your entire JavaScript application.

WELL DONE.

Once you’re confident with basic Web Worker messaging, the next step is to explore SharedArrayBuffer and Atomics. These tools unlock true parallelism in JavaScript by allowing multiple threads to share and safely modify the same memory region without copying data back and forth. Learning them gives you finer control over performance, synchronization, and real-time data processing — essential skills if you want to master advanced concurrency patterns and high-performance applications in the browser or Node.js.

My final words.