14 comments

[ 3.8 ms ] story [ 36.5 ms ] thread
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.

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.
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.

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 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.

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();