# Promise based Web Worker Messaging

DevFeed: [Promise based Web Worker Messaging](<https://devfeed.tech/articles/promise-based-web-worker-messaging-37370.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/web-workers-promises/>)

Author: Stanko

Published: 2025-11-03T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [Promise](<https://devfeed.tech/topics/promise.md>), [Messaging](<https://devfeed.tech/topics/messaging.md>), [Web](<https://devfeed.tech/topics/web.md>), [async/await](<https://devfeed.tech/topics/async-await.md>), [Code](<https://devfeed.tech/topics/code.md>), [Error Handling](<https://devfeed.tech/topics/error-handling.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [await](<https://devfeed.tech/tags/await.md>), [code](<https://devfeed.tech/tags/code.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [event](<https://devfeed.tech/tags/event.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [messaging](<https://devfeed.tech/tags/messaging.md>), [thread](<https://devfeed.tech/tags/thread.md>), [web](<https://devfeed.tech/tags/web.md>), [worker](<https://devfeed.tech/tags/worker.md>)

## AI overview

This tutorial presents a Promise-based wrapper for Web Worker messaging. It explains how unique message identifiers map worker responses to stored promises, allowing the main thread to resolve or reject the corresponding promise and use async/await with simpler error handling. The same pattern can also be applied to Service Workers.

## Source excerpt

If you've ever used Web Workers (or any other event-based communication), you probably noticed that this kind of code can be hard to read and reason about. You also have to implement some kind of identifier for each message to recognize which worker response corresponds to which request. To simplify that, we can write a small wrapper that lets us use Promises to communicate with Workers. I'll show you an example for Web Workers, but the same pattern can be applied to Service Workers as well. The resulting API looks like this: const workerResponse = await sendToWorker(data); I first used this approach in Pulsar, because I wanted to parse and execute the user's code in a Web Worker, but also wait for the worker to finish before providing data for the next frame. Implementation # The idea is fairly simple - before sending a message to the worker, we create a unique id and a promise. We store the promise in a map using the id as the key. Then we send an event to the worker, including both the data and the id, and return the promise to the caller. When the worker finishes its calculation, it sends back a message that includes the result and the same id. In the main thread, we listen for these messages. When one arrives, we use the id to find the corresponding promise in our map. Finally, based on the worker's result, we resolve or reject that promise. It might sound like a lot, but the code is actually quite straightforward: send-to-worker.jsCopy // Worker initialization const worker = new Worker("./path-to-your-worker.js"); // Map of promises const promises = {}; worker.addEventListener("message", (e) => { // Listen to worker messages and find the correct promise matching the id // Then resolve or reject it depending on the response if (e.data.error) { promises[e.data.id].reject(e.data.error); } else { promises[e.data.id].resolve(e.data.data); } // Remove the resolver reference delete promises[e.data.id]; }); // For identifiers it is safe to use a simple integer // whic