Absolutely agreed. We should be able to debug Web Workers with development tools (e.g. set breakpoints / examine state / etc), nest Web Workers, use console.log from within a Worker, and construct Web Workers from Blob URLs. It's infuriatingly difficult to work with Web Workers without these features, which are missing from most browsers!
I think there's a chicken-and-egg problem with regards to Web Workers: Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. Someone needs to break the cycle.
There's also a host of nasty bugs and implementation deficiencies, depending on the browser.
My favorite is in Chrome with simple DedicatedWorker instances communicating with each other directly via the MessageChannel API. It works, except when the UI thread is blocked, because messages are routed through the UI thread. Firefox doesn't have this problem, but it has its own issues—namely the UI thread for each tab runs in the same OS process, unlike Chrome where tabs are isolated processes.
That said, Firefox and Chrome are far ahead of every other browser in terms of how they implement workers. Other implementations are borderline destitute by comparison (e.g. no DOMHighResTimeStamp available in worker context, no Transferable support for important items).
>Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption.
You hit the nail on the head. I think it's also a dislike for the API as a whole, because really workers are just a convoluted way of enforcing thread safety. Personally I'd prefer a far more simple and traditional shared memory model, with developers being afforded enough rope to hang themselves with if they so desired.
The existing methods of transferring data to and from workers are frankly crap, the only light at the end of the tunnel being SharedArrayBuffer and the Atomics API designed around it. The problem is that both are essentially designed for compiled applications, ala asm.js and WebAssembly. In a compiled [browser] environment, the heap is seamlessly allocated on a SharedArrayBuffer, so writing parallel code is nearly identical to the traditional desktop experience from a developer's point of view. In plain old Javascript however, you have to serialize and deserialize native types to and from the buffer, which is expensive. It really makes Javascript seem like a second-class citizen with regards to parallelism.
> It works, except when the UI thread is blocked, because messages are routed through the UI thread.
This bug actually causes a ~40% slowdown in one of my projects, since I use sendMessage() in a Worker context to quickly yield to the browser. I didn't mention it, since I figured it may have been fairly obscure... I'm somewhat glad to hear that others are experiencing pain from it. It gives me some hope that it'll eventually be addressed!
Right. My point was that the way the API is built is definitely more friendly towards compiled use cases. With JS, you have to manually serialize and deserialize virtually everything that transits the buffer.
I think there's a chicken-and-egg problem with regards to Web Workers: Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. Someone needs to break the cycle.