One alternative to Comlink is to use IndexedDB transactions and polling.

IndexedDB can be shared amongst Web Workers for the same origin (localStorage cannot).

https://dexie.org is a nice IndexedDB library.

As an example, if you have many web workers, each can write their current state or use transactions to take items from a queue, and a central UI can just query the single IndexedDB.

I use both Comlink and Dexie, for different purposes.

Comlink gives a seamless abstraction over the worker "bridge", and Dexie does the same for the complex IDB API.

I have run into performance issues with Dexie when querying lots of objects (~1M) from a collection, but it looks like it's more of a limitation on IndexedDB itself.

Wow, I had no idea about this! What do you think is the current state of adoption for IndexedDB apart from fingerprinting?

I'm not sure to be honest, https://caniuse.com/indexeddb lists >95% for browser implementations.

I quite like IndexedDB as it is widely supported by browsers.

Although for simple data I prefer the sync localStorage API.

It's the same for me! sessionStorage is handy as well for things like autocomplete result caching. Was wondering about adoption in usage, not implementation.

Used Comlink for a small toy project and made it really easy with very little change to move an expensive file merge off the main thread and do it in the background. Next time I use WebWorkers I'll probably use Comlink.

Example of using here https://github.com/mrloop/activity-merge/blob/main/app/contr...

I've used Comlink in a production React app (for client-side text search) and enjoyed it.

The lib author wrote a nice blog post about "why webworkers" and "why comlink" a few years ago: https://surma.dev/things/when-workers/

Interesting. Question due to unfamiliarity - how reliable are Web Workers? If the main UI thread is up and running, is it safe to assume that any created workers are also running and able to receive/send messages?

Think of webworkers as forked subprocesses. You can create them from a script interact, then kill them.

They're basically the future of any serious web first PWA where you're not even concerned about a server doing anything.

Can it run untrusted worker code in "sandbox iframe" mode? Something like jailed. Or do these both go together?

I'd not trust anyt webworkers as a jail.

Look into quickjs if you want untrusted JavaScript in the browser.

A quick read suggests it's note wiring iframe comes which requires another abstractions.

properly sandboxed iframe is pretty secure and qjs is big and written in C.

Anyway from a quick read I saw that plenty people use comlink with iframes, thanks though

I've used it and it's convenient - but the example I saw in the screenshot made me a bit suspicious at first.

  const instance = await new MyClass();

A similar thing https://github.com/WebReflection/coincident