Right now things are a mess in Web Worker land, and have been for quite some time.
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.
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.
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!
Still, it's nice to see the spec move forward.
Being actively worked on, as far as I can tell. I agree that not having this sucks.
> nest Web Workers
Works in Firefox; haven't tested in Edge.
> use console.log from within a Worker
Works in Firefox and Chrome, fails in Safari, haven't tested in Edge.
> construct Web Workers from Blob URLs
Works in every modern browser, I believe.