3 ms·

Is it fair to describe JS as single-threaded when all modern browsers support web workers? Related: Why does it seem like web workers don't exist? I can hardly

by crabasa 13y ago

Is it fair to describe JS as single-threaded when all modern browsers support web workers? Related: Why does it seem like web workers don't exist? I can hardly think of any popular libraries or web apps that make use of them, despite the seemingly obvious utility.

tachyonbeam 13y ago
Web workers are more like multiple processes than multiple threads, but yes, there are ways to use more than one CPU core in JS too.
danmaz74 13y ago
Our hashtagify.me uses them :)
kybernetikos 13y ago
After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread. Of course this was in the early days, and it'd be good to retest it to see if it's better now. I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.
- Yoric 13y ago
  Working on it :)
- i_s 13y ago
  It is still not good. I've started working on an asteroids game [0], and I tried moving my physics calculations to a background thread, but it ended up being slower. 0 http://www.isaksky.com/asteroids/ http://www.isaksky.com/asteroids/
Yoric 13y ago
Let me detail tachyonbeam's answer. All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment. Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-javascript/) http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency. Note: I'm a Firefox dev.
cwmma 13y ago
1. It's hard to use them in libraries due to restrictions on how to load them, Opera, Ie 10 and safari 5 require a same origin file, makes it hard to drop a worker into a slow part of jQuery. 2. Message passing can be slow and transferring only works for typed arrays which take time to convert to. Unless your calculations are much bigger then your data or converting to typed arrays isn't a bottleneck it may slow you down. 3. OO based inheritance patterns make it very hard to put pieces of your code into the worker, if your slow thing involved a call to jQuery. Ajax you can't call jQuery from the worker because it references the DOM but you can't pull out the Ajax method because it relies on $. extend and others meaning you have to rewrite $. Ajax from scratch (mot too bad in this case) or do major surgery on the library.

by crabasa 13y ago

tachyonbeam 13y ago

Web workers are more like multiple processes than multiple threads, but yes, there are ways to use more than one CPU core in JS too.

danmaz74 13y ago

Our hashtagify.me uses them :)

kybernetikos 13y ago

After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread. Of course this was in the early days, and it'd be good to retest it to see if it's better now. I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.

Yoric 13y ago
Working on it :)
i_s 13y ago
It is still not good. I've started working on an asteroids game [0], and I tried moving my physics calculations to a background thread, but it ended up being slower. 0 http://www.isaksky.com/asteroids/ http://www.isaksky.com/asteroids/

Yoric 13y ago

Let me detail tachyonbeam's answer. All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment. Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-javascript/) http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency. Note: I'm a Firefox dev.

cwmma 13y ago

1. It's hard to use them in libraries due to restrictions on how to load them, Opera, Ie 10 and safari 5 require a same origin file, makes it hard to drop a worker into a slow part of jQuery. 2. Message passing can be slow and transferring only works for typed arrays which take time to convert to. Unless your calculations are much bigger then your data or converting to typed arrays isn't a bottleneck it may slow you down. 3. OO based inheritance patterns make it very hard to put pieces of your code into the worker, if your slow thing involved a call to jQuery. Ajax you can't call jQuery from the worker because it references the DOM but you can't pull out the Ajax method because it relies on $. extend and others meaning you have to rewrite $. Ajax from scratch (mot too bad in this case) or do major surgery on the library.