Live data from Hacker News

JavaScript in Parallel: Web Workers and SharedArrayBuffer

50linesofco.de

21–30 of 74 posts

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#22
If you don't like to have to load an external file (+ an extra request) you can use my library uwork: https://github.com/franciscop/uwork

It has some limitations, but for long lived process intensive and async functions is perfect. It has a really clean and easy syntax where you don't need to learn everything about Web Workers and their APIs to be able to use it.

If you are already using promises you might not even need anything besides wrapping the function in a callback.

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#23

What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.

I've used it for background image manipulation before.

Paint the image to a canvas, then grab the imagedata off of it, split it into as many parts as you have threads, then use the "transferrableObjects" property of postMessage to zero-copy transfer the data to each worker to be processed, transferred back, and re-stitched together.

It's pretty powerful and suprisingly easy to work with once you understand it.

[0] is a snippet from the code, but be gentile... It was a personal project where I was trying out polymer 0.5 and made a lot of questionable design choices...

Also, I've heard of the idea of using webworkers as a "first class" platform. That is do all of the core parts of your application in them and only use the "main" thread as a "ui" thread. I haven't gotten a chance to try it out, but it seems like a great idea that could really work well in some SPAs.

[0] https://github.com/Klathmon/stitchpics/blob/master/app/eleme...

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#24
post #18

Earlier quoted context omitted.

I used WebWorkers for some math - basically lots of Fourier transforms, which took a few seconds to complete. I expected to instantiate a WebWorker with a function, and was surprised to discover you have to give it a separate JavaScript file. It is not easy to adopt.

You can just call toString on a function and Blob the string. You have to keep your head straight about the fact that scopes won't transfer (no closures), which is probably why the API doesn't do it for you.

This didn't work in my case because I had references to other functions, for complex number handling and the like. I ended up just loading the whole minified .js file again in the Worker, which worked though it felt ridiculous.

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#25

What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.

Build thumbnail of images, encode audio/video, upload a file in background. Anything that takes more than a few seconds.

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#28

What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.

In an embedded application with low resources you could push processing into a worker if your CPU is multi core.

Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer

#30

I'd just like some high level guidance on how my browser makes use of threads internally. I feel like I could have further optimized a couple web apps with that knowledge.

Excluding web workers, just one thread per tab/window. So there's really no consideration for optimization via. parallelism unless you use web workers.

And if I'm wrong, this is the quickest way to get the right info. :)

Post reply on HN