Hacker News Reader

Comment by bbcbasic | Hacker News Reader

Threads in JS?

Web workers are threaded.

They are more akin to "processes", because they don't share state with each other or the main event loop.

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.

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.

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/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/

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... 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.

> You can use Web Sockets in Web Workers in very recent Firefox (48+?)

38+. It's been shipping for a year and a half.

Off by 10 errors are my specialty!!

Good to know it's stable for awhile, thanks for the update. Go Mozilla, go!!

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...

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.

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.

Reply on news.ycombinator.com