Web Workers for parallel processing in Deno - Deep Dive

Overview - Web Workers for parallel processing

What is it?

Web Workers are a way to run JavaScript code in the background, separate from the main program. This lets your app do many things at once without slowing down the user interface. In Deno, Web Workers allow you to run scripts in parallel, making heavy tasks faster and smoother. They work by creating separate threads that communicate with the main program through messages.

Why it matters

Without Web Workers, heavy tasks like calculations or data processing block the main program, making apps freeze or feel slow. Web Workers solve this by running tasks in parallel, so the app stays responsive and fast. This improves user experience and lets developers build more powerful, efficient applications.

Where it fits

Before learning Web Workers, you should understand basic JavaScript and asynchronous programming concepts like promises. After mastering Web Workers, you can explore advanced parallel processing techniques, shared memory with Atomics, and performance optimization in Deno.

Mental Model

Core Idea

Web Workers run code in separate threads so your main program can keep running smoothly without waiting.

Think of it like...

It's like having a helper in another room doing a task for you while you keep working without interruption.

Main Thread ──────▶ User Interface (Responsive)
       │
       │
       ▼
  ┌───────────┐
  │ Web Worker│
  │ (Background│
  │   Thread) │
  └───────────┘
       ▲
       │
  Message Passing

Build-Up - 7 Steps

1

Foundation

Understanding single-threaded JavaScript

Concept: JavaScript normally runs one command at a time on a single thread.

JavaScript executes code line by line on the main thread. If a task takes a long time, it blocks everything else, including the user interface. This means the app can freeze or become unresponsive during heavy work.

Result

The app can freeze or lag during long tasks because everything waits for the current task to finish.

Understanding that JavaScript is single-threaded explains why heavy tasks block the app and why we need a way to run code in parallel.

2

Foundation

Basics of asynchronous programming

Concept: JavaScript can handle some tasks asynchronously to avoid blocking the main thread.

Using promises, async/await, and callbacks, JavaScript can start tasks that run in the background, like fetching data, and continue running other code. But this does not create new threads; it just schedules tasks efficiently.

Result

The app stays responsive during I/O tasks, but CPU-heavy tasks still block the main thread.

Knowing async programming helps understand its limits and why Web Workers are needed for CPU-heavy parallel work.

3

Intermediate

Creating and using Web Workers in Deno

🤔Before reading on: do you think Web Workers share variables with the main thread or have separate memory? Commit to your answer.

Concept: Web Workers run scripts in separate threads with their own memory and communicate via messages.

In Deno, you create a Worker by giving it a script file. The worker runs independently. You send messages to it using postMessage and listen for messages with onmessage. The worker cannot directly access variables from the main thread.

Result

Heavy tasks run in the worker thread without blocking the main thread, and results come back via messages.

Understanding that workers have separate memory and communicate only by messages is key to using them correctly and avoiding bugs.

4

Intermediate

Message passing between main and worker threads

🤔Before reading on: do you think messages between threads are synchronous or asynchronous? Commit to your answer.

Concept: Communication between main and worker threads happens asynchronously through message passing.

Both main and worker threads use postMessage to send data and onmessage to receive it. Messages are copied, not shared, so changes in one thread do not affect the other directly. This keeps threads isolated and safe.

Result

Data flows between threads without blocking, enabling parallel processing with safe communication.

Knowing message passing is asynchronous and copies data helps avoid mistakes like expecting shared state or immediate responses.

5

Advanced

Handling errors and termination in workers

🤔Before reading on: do you think errors in a worker crash the main program? Commit to your answer.

Concept: Errors in workers do not crash the main thread but must be handled explicitly. Workers can be terminated to free resources.

Workers emit error events that the main thread can listen to and handle gracefully. You can stop a worker anytime using worker.terminate(), which stops its execution and frees memory.

Result

Your app stays stable even if a worker fails, and you can control worker lifecycle to optimize resource use.

Understanding error isolation and lifecycle control prevents crashes and resource leaks in production apps.

6

Expert

Optimizing performance with transferable objects

🤔Before reading on: do you think large data sent between threads is copied or moved? Commit to your answer.

Concept: Transferable objects let you move data between threads without copying, improving performance.

By passing transferable objects like ArrayBuffers with postMessage, ownership transfers to the receiver, avoiding costly data copies. This is crucial for large data like images or buffers in parallel processing.

Result

Data moves faster between threads, reducing overhead and speeding up parallel tasks.

Knowing how to use transferable objects unlocks high-performance parallel processing and avoids hidden slowdowns.

7

Expert

Shared memory and Atomics for advanced synchronization

🤔Before reading on: do you think Web Workers can share memory directly? Commit to your answer.

Concept: Web Workers can share memory using SharedArrayBuffer and coordinate with Atomics for safe concurrent access.

SharedArrayBuffer allows multiple threads to access the same memory space. Atomics provide methods to read, write, and wait safely, preventing race conditions. This enables complex parallel algorithms but requires careful design.

Result

You can build highly efficient parallel programs with shared state and synchronization.

Understanding shared memory and Atomics is essential for expert-level parallel programming beyond simple message passing.

Under the Hood

Web Workers run in separate threads managed by the Deno runtime and the underlying operating system. Each worker has its own JavaScript engine instance and memory heap, isolated from the main thread. Communication happens via a message queue system where messages are serialized and sent asynchronously. Transferable objects optimize this by transferring ownership instead of copying. Shared memory uses special buffers accessible by multiple threads with atomic operations to prevent conflicts.

Why designed this way?

JavaScript was originally single-threaded to keep things simple and avoid complex bugs from shared memory. Web Workers were introduced to allow parallelism without breaking this model by isolating threads and forcing communication through messages. This design balances safety, simplicity, and performance. Alternatives like shared memory were added later for advanced use cases but require more care.

┌───────────────┐       ┌───────────────┐
│   Main Thread │──────▶│   Worker 1    │
│ (UI & Logic)  │◀──────│ (Background)  │
└───────────────┘       └───────────────┘
        │                      │
        │                      │
        ▼                      ▼
  Message Queue           Message Queue
        │                      │
        ▼                      ▼
  Event Loop              Event Loop

Memory: Separate heaps for main and worker
Communication: Asynchronous message passing
Optional: SharedArrayBuffer with Atomics for shared memory

Myth Busters - 4 Common Misconceptions

Quick: Do Web Workers share variables directly with the main thread? Commit to yes or no.

Common Belief: Web Workers share the same variables and memory as the main thread.

Reality: Web Workers have separate memory and cannot access main thread variables directly; they communicate only via messages.

Why it matters: Expecting shared variables causes bugs and confusion because changes in one thread do not affect the other.

Quick: Are messages between main and worker threads synchronous or asynchronous? Commit to your answer.

Common Belief: Messages between threads happen instantly and block until received.

Reality: Messages are sent asynchronously and do not block the sender or receiver.

Why it matters: Assuming synchronous messaging leads to incorrect code that waits unnecessarily or misses timing issues.

Quick: If a worker throws an error, does it crash the whole app? Commit to yes or no.

Common Belief: Errors inside a worker crash the main program.

Reality: Worker errors are isolated and must be handled explicitly; they do not crash the main thread.

Why it matters: Not handling worker errors can cause silent failures or unexpected app behavior.

Quick: When sending large data to a worker, is it copied or moved? Commit to your answer.

Common Belief: All data sent to workers is copied, which is slow for large data.

Reality: Transferable objects can be moved without copying, improving performance.

Why it matters: Ignoring transferable objects leads to slow data transfer and poor app performance.

Expert Zone

1

Workers can spawn other workers, creating a hierarchy of parallel tasks, but this increases complexity and resource use.

2

Using SharedArrayBuffer requires careful synchronization with Atomics to avoid subtle bugs like race conditions or deadlocks.

3

Terminating a worker does not automatically clean up all resources; proper lifecycle management is essential to prevent memory leaks.

When NOT to use

Web Workers are not suitable for tasks that require frequent, low-latency communication or shared mutable state without careful synchronization. For such cases, consider using native extensions, Rust plugins with FFI, or server-side parallelism. Also, for very small tasks, the overhead of creating workers may outweigh benefits.

Production Patterns

In production, Web Workers are used for heavy computations like image processing, data parsing, or cryptography. Patterns include worker pools to reuse threads efficiently, message batching to reduce overhead, and fallback strategies for environments without worker support. Monitoring worker health and error handling are critical for robust apps.

Connections

Operating System Threads

Web Workers are JavaScript's abstraction over OS threads for parallelism.

Understanding OS threads helps grasp how Web Workers map to real system resources and why isolation and message passing are necessary.

Actor Model in Concurrent Computing

Web Workers follow the actor model by isolating state and communicating via messages.

Knowing the actor model clarifies why Web Workers avoid shared state and use asynchronous messaging to prevent concurrency bugs.

Human Teamwork

Like team members working independently and communicating updates, Web Workers run tasks separately and share results.

This connection helps appreciate the importance of clear communication and task division in parallel programming.

Common Pitfalls

#1 Trying to access main thread variables directly inside a worker.

Wrong approach:

console.log(sharedVariable); // inside worker script

Correct approach:

self.onmessage = (e) => { const sharedVariable = e.data; console.log(sharedVariable); };

Root cause:

Misunderstanding that workers have separate memory and cannot see main thread variables.

#2 Sending large data objects without using transferable objects, causing slow performance.

Wrong approach:

worker.postMessage(largeArrayBuffer); // copies data

Correct approach:

worker.postMessage(largeArrayBuffer, [largeArrayBuffer]); // transfers ownership

Root cause:

Not knowing about transferable objects and their performance benefits.

#3 Not handling errors from workers, leading to silent failures.

Wrong approach:

const worker = new Worker('worker.js'); // no error event listener

Correct approach:

worker.addEventListener('error', (e) => { console.error('Worker error:', e.message); });

Root cause:

Assuming worker errors automatically propagate to the main thread.

Key Takeaways

Web Workers let you run JavaScript code in parallel threads to keep your app responsive during heavy tasks.

Workers have separate memory and communicate with the main thread only through asynchronous message passing.

Using transferable objects improves performance by moving data instead of copying it between threads.

Proper error handling and lifecycle management of workers are essential for stable and efficient applications.

Advanced parallelism can use shared memory with Atomics, but this requires careful synchronization to avoid bugs.

Practice

1. What is the main purpose of using Web Workers in Deno?

easy

A. To create a new HTTP server

B. To run tasks in parallel without blocking the main thread

C. To manage file system permissions

D. To handle database connections

Solution

1. Step 1: Understand Web Workers role

   Web Workers allow running scripts in background threads separate from the main thread.

2. Step 2: Identify the benefit

   This prevents the main thread from freezing during heavy tasks, enabling parallel processing.

3. Final Answer:

   To run tasks in parallel without blocking the main thread -> Option B

4. Quick Check:

   Web Workers = Parallel tasks without blocking [OK]

Hint: Web Workers run code in background threads [OK]

Common Mistakes:

• Thinking Web Workers handle HTTP or database tasks directly
• Confusing Web Workers with main thread code
• Assuming Web Workers manage permissions

2. Which of the following is the correct way to send a message from the main thread to a Web Worker in Deno?

easy

A. worker.postMessage('Hello')

B. worker.emit('Hello')

C. worker.send('Hello')

D. worker.message('Hello')

Solution

1. Step 1: Recall message sending method

   In Web Workers, the method to send data to the worker is postMessage.

2. Step 2: Match correct syntax

   Among the options, only worker.postMessage('Hello') is valid and recognized.

3. Final Answer:

   worker.postMessage('Hello') -> Option A

4. Quick Check:

   Send message = postMessage [OK]

Hint: Use postMessage to send data to workers [OK]

Common Mistakes:

• Using send() instead of postMessage()
• Confusing emit() with event emitters
• Trying to call message() which doesn't exist

3. Consider this Deno Web Worker code snippet:

const worker = new Worker(new URL('./worker.ts', import.meta.url).href, { type: 'module' });
worker.onmessage = (e) => console.log('Result:', e.data);
worker.postMessage(5);

And the worker.ts contains:

self.onmessage = (e) => {
  const num = e.data;
  self.postMessage(num * 2);
};

What will be printed in the console?

medium

A. Result: 10

B. Result: 5

C. Result: undefined

D. No output, error occurs

Solution

1. Step 1: Understand message flow

   The main thread sends 5 to the worker. The worker receives it as num.

2. Step 2: Calculate worker response

   The worker multiplies 5 by 2 and sends back 10. The main thread logs 'Result: 10'.

3. Final Answer:

   Result: 10 -> Option A

4. Quick Check:

   5 * 2 = 10 output [OK]

Hint: Worker doubles input and sends back result [OK]

Common Mistakes:

• Assuming worker returns original number
• Confusing onmessage event usage
• Expecting error due to URL usage

4. What is wrong with this Deno Web Worker code snippet?

const worker = new Worker('./worker.ts', { type: 'module' });
worker.postMessage('start');
worker.onmessage = (e) => console.log(e.data);
worker.terminate();

medium

A. Worker path './worker.ts' is invalid in Deno

B. postMessage is called before onmessage, causing error

C. Worker is terminated immediately, so no message is received

D. Missing event listener for error events

Solution

1. Step 1: Analyze termination timing

   The worker is terminated right after sending the message, likely before it can respond.

2. Step 2: Effect on message reception

   Because of immediate termination, the onmessage handler never receives data.

3. Final Answer:

   Worker is terminated immediately, so no message is received -> Option C

4. Quick Check:

   Terminate too soon = no response [OK]

Hint: Terminate workers only after receiving messages [OK]

Common Mistakes:

• Thinking postMessage order causes error
• Ignoring worker path resolution rules
• Forgetting to handle errors but not critical here

5. You want to process a large array of numbers in parallel using Deno Web Workers. Which approach correctly splits the work and collects results efficiently?

hard

A. Process the array in the main thread without workers for simplicity

B. Create one worker and send the entire array repeatedly for each number

C. Use a single worker and process numbers sequentially inside it

D. Create multiple workers, send each a slice of the array, collect partial results, then combine them

Solution

1. Step 1: Understand parallel processing strategy

   Splitting the array into parts and assigning each to a separate worker allows true parallelism.

2. Step 2: Collect and combine results

   Each worker returns partial results; the main thread combines them for the final output.

3. Final Answer:

   Create multiple workers, send each a slice of the array, collect partial results, then combine them -> Option D

4. Quick Check:

   Split work + combine results = efficient parallelism [OK]

Hint: Split data among workers, then merge results [OK]

Common Mistakes:

• Sending full array multiple times wastes resources
• Using one worker loses parallel benefit
• Ignoring main thread processing slows app