I hope there are simple ways to disable these on browsers.
Can't imagine every tab having a load of workers in the background, ending well.
One of the pleasant things about javascript is that there are no threads. It's a shame some people have pushed for this API.
After all, it's not rocket science for a competent developer to split a long running task into chunks which are periodically run via a timeout, keeping the UI responsive.
While I agree most things could be split into chunks with a timeout, there's definitely a place for web workers, for example in canvas image processing.
I wholeheartedly agree. I had some code that had to parse several different .ply files and creat the respective 3D models, and without web workers, the process was unbearably long.
i'm currently a little pissed at webwokers (yeah, i take it personally) that i can't hand them a canvaspixelarray. so basically to use workers for canvasimagemanipulation you have to copy the canvaspixelarray into an uint8array, pass it to the work, get back a uint8array and copy that one back into the imagedata.data canvaspixelarray. oh yeah, the copy actions are of course all in the main thread - so this basically defeats the reason to have webworkers in the first place.
the newest chrome has support for transferable objects that can be sent directly to a worker without being copied. this works with ArrayBuffer now, not sure if ImageData is transferable yet, but it should be eventually.
6 comments
[ 2.2 ms ] story [ 27.4 ms ] threadCan't imagine every tab having a load of workers in the background, ending well.
One of the pleasant things about javascript is that there are no threads. It's a shame some people have pushed for this API.
After all, it's not rocket science for a competent developer to split a long running task into chunks which are periodically run via a timeout, keeping the UI responsive.
demo: http://html5-demos.appspot.com/static/workers/transferables/...