5 ms·

Threads in JS?

by bbcbasic 10y ago

Threads in JS?

EdSharkey 10y ago
Web workers are threaded.
- hrjet 10y ago
  They are more akin to "processes", because they don't share state with each other or the main event loop.
- throwaway2048 10y ago
  web workers are almost entirely useless due to the fact they cant interact with anything except a message channel. Serializing and deserializing everything so web workers can operate on it introduces more overhead than the parallel speedup is worth in the vast majority of cases. Not to mention stuff like DOM updates, web-sockets, or anything else cant be done by them, and are stuck on the main thread. They are really not comparable to threads.
  - jbergens 10y ago
    They are mostly done in order to free the ui "thread" to avoid getting ui freeze. The event loop is fast enough for most concurrency things in js client applications as long as you divide the tasks into smaller things.
  - EdSharkey 10y ago
    I suppose if you could only crunch numbers in a Web Worker and then make a clone to get it back to the DOM thread where it would be used, then yeah, Web Workers would be bleh. But, it's not as bad as all that! For example, transferables let you move bulk data between threads without cloning. At least that removes most of the communication overhead. https://developer.mozilla.org/en-US/docs/Web/API/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl... On firefox you can transfer your WebGL canvas to a Web Worker, how is that for useful? https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ You can use Web Sockets in Web Workers in very recent Firefox (48+?) and Chrome versions. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... And you've always been able to do AJAXy things on Web Workers as well. I'm not saying the API's are clean or lovely, but the multithreaded functionality is there for the taking.
    - bzbarsky 10y ago
      > You can use Web Sockets in Web Workers in very recent Firefox (48+?) 38+. It's been shipping for a year and a half.
      - EdSharkey 10y ago
        Off by 10 errors are my specialty!! Good to know it's stable for awhile, thanks for the update. Go Mozilla, go!!
  - dcherman 10y ago
    That's not true at all, and I expect them to become increasingly important over time. Now that we have the DOM being abstracted away into the virtual DOM in React, Angular 2, Vue, etc., it should be almost entirely possible to run your framework code entirely in a WebWorker while sending back some type of delta/patch to update the actual DOM. I'm not sure what you mean that web sockets aren't supported since the MDN shows it as being fully available: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... Where this falls down is in handling events where some actions inherently need to be synchronous (preventDefault, stopPropagation), however I think Angular 2 was starting to consider options on how to overcome that. I can't speak for progress in other frameworks.
  - bzbarsky 10y ago
    You can do websocket in web workers. At least per spec, and in anything resembling a recent Firefox; it was shipped in Firefox 38 about a year and a half ago. I can't speak for other browsers. You can also do XMLHttpRequest and fetch in web workers. And IndexedDB, so you can store stuff persistently from a worker and then read it back from a worker later. I agree that if you want to hand out data on the client to a worker pool after getting all the data from somewhere in the main page script, then serialization/deserialization can start to bite.

Threads in JS?

EdSharkey 10y ago

Web workers are threaded.

hrjet 10y ago
They are more akin to "processes", because they don't share state with each other or the main event loop.
throwaway2048 10y ago
web workers are almost entirely useless due to the fact they cant interact with anything except a message channel. Serializing and deserializing everything so web workers can operate on it introduces more overhead than the parallel speedup is worth in the vast majority of cases. Not to mention stuff like DOM updates, web-sockets, or anything else cant be done by them, and are stuck on the main thread. They are really not comparable to threads.
- jbergens 10y ago
  They are mostly done in order to free the ui "thread" to avoid getting ui freeze. The event loop is fast enough for most concurrency things in js client applications as long as you divide the tasks into smaller things.
- EdSharkey 10y ago
  I suppose if you could only crunch numbers in a Web Worker and then make a clone to get it back to the DOM thread where it would be used, then yeah, Web Workers would be bleh. But, it's not as bad as all that! For example, transferables let you move bulk data between threads without cloning. At least that removes most of the communication overhead. https://developer.mozilla.org/en-US/docs/Web/API/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl... On firefox you can transfer your WebGL canvas to a Web Worker, how is that for useful? https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/ You can use Web Sockets in Web Workers in very recent Firefox (48+?) and Chrome versions. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... And you've always been able to do AJAXy things on Web Workers as well. I'm not saying the API's are clean or lovely, but the multithreaded functionality is there for the taking.
  - bzbarsky 10y ago
    > You can use Web Sockets in Web Workers in very recent Firefox (48+?) 38+. It's been shipping for a year and a half.
    - EdSharkey 10y ago
      Off by 10 errors are my specialty!! Good to know it's stable for awhile, thanks for the update. Go Mozilla, go!!
- dcherman 10y ago
  That's not true at all, and I expect them to become increasingly important over time. Now that we have the DOM being abstracted away into the virtual DOM in React, Angular 2, Vue, etc., it should be almost entirely possible to run your framework code entirely in a WebWorker while sending back some type of delta/patch to update the actual DOM. I'm not sure what you mean that web sockets aren't supported since the MDN shows it as being fully available: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... Where this falls down is in handling events where some actions inherently need to be synchronous (preventDefault, stopPropagation), however I think Angular 2 was starting to consider options on how to overcome that. I can't speak for progress in other frameworks.
- bzbarsky 10y ago
  You can do websocket in web workers. At least per spec, and in anything resembling a recent Firefox; it was shipped in Firefox 38 about a year and a half ago. I can't speak for other browsers. You can also do XMLHttpRequest and fetch in web workers. And IndexedDB, so you can store stuff persistently from a worker and then read it back from a worker later. I agree that if you want to hand out data on the client to a worker pool after getting all the data from somewhere in the main page script, then serialization/deserialization can start to bite.