tldr; worker libraries are a catch-22: they help a lot for people who don’t need them, and they don’t help much for people who do need them. I had a pretty cle

tldr; worker libraries are a catch-22: they help a lot for people who don’t need them, and they don’t help much for people who do need them. I had a pretty clear use-case: running a cpu-hungry ML model at 5-10 FPS without locking a dynamic UI that needed to stay around 60fps. I tried out all the various worker libraries: thread.js, comlink, etc. What I found is that while these libraries do make it easier to get a worker up and running, they introduce abstractions that make it harder to achieve the goal of using workers in the first place: performance. The browser APIs for WebWorkers are not difficult to learn and use. But stashing code into a worker doesn’t magically solve performance issues. It’s just the first step. In my case, I had to optimize the transfer of data to and from the worker. Any abstraction that sits in front of that transfer ends up being at best being an additional and unnecessary cognitive load, and at worst being an obstacle to my original goal of improving performance. While I’m sure these libraries take pains to ensure they don’t do anything that might impact performance, the slightest possibility of a library’s contribution to degraded performance means that your cognitive load now includes ensuring the library is performant too. It’s analogous to hunting down a tricky bug. Whenever I get a bug that is particularly hard to understand, I end up performing dramatic (albeit temporary) surgery on the codebase to remove anything extraneous to the bug. If I can remove 95% of the code, then I only need to think about 5% of the code. While it is true that the code I removed had nothing to do with the bug, my eyes and brain have an easier time ignoring code that doesn’t exist rather than code that doesn’t matter. Same for these worker libraries. It’s more code that you have to consider. And if you are using a worker for a good reason — to solve a hard performance issue — you really don’t want to have to consider any more lines of code than absolutely necessary, and ideally you only have to consider lines you’ve written yourself. I’m not usually in the camp of “write everything yourself”, but leveraging WebWorkers for performance is one of those cases where you are going to get your hands dirty anyway. You might as well embrace it from the start. Now, if you already understand workers inside and out, then these libraries probably would save you time and be less bug-prone in handling thorny use-cases like workers that run in isometric codebases. Ironically, those who least need a library gain the most from it, while those who most need a library gain the least from it.