Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When to use web workers

dassur.ma

Post reply on HN
Print view View original

81–90 of 110 posts

Re: When to use web workers

#81

Post by Ruphin »

dassurma wrote: post #68
Ruphin wrote: post #67

Earlier quoted context omitted.

Ah, I messed up in my haste to experiment :) I expaned my tests a bit and your version does indeed queue a task and not a micro task. I did find it to be somewhat less reliable than setTimeout, is there a particular reason why you used this scheme instead of a setTimeout based solution to queue tasks? Why did you choose this method in particular to queue tasks? Also, AsyncTask and MicroTask are not fully equivalent.…

Why do you think it's less reliable? setTimeout gets clamped by the browser to a minimum of 4ms, so you waste a lot of time when all you want is a task boundary.

I tried so many janky different ways that I don't quite remember how to reproduce it, but I found that setTimeout was more likely to always execute once per animationFrame, where using MessageChannel would sometimes execute more than once per frame. I guess the minimum timeout added to setTimeout makes it more likely to not hit twice between paints. The test setup I have now gets pretty clean results.

One final question would be why you have this uid system with attaching and removing event listeners? I think MessageChannels are order preserving, so you can do with a single EventListener that consumes events off a queue, or am I missing something?

``` const { port1, port2 } = new MessageChannel(); const taskQueue = []; port2.start(); port2.addEventListener("message", () => { taskQueue.shift()(); });

const task = () => { return new Promise(resolve => { taskQueue.push(resolve); port1.postMessage(0); }); }

```

Re: When to use web workers

#82

Post by Jack000 »

stefan_ wrote: post #65
Matheus28 wrote: post #50

Earlier quoted context omitted.

“I don’t use it, therefore no one else uses it” As an example, emscripten uses WebWorkers and SharedArrayBuffers to implement multithreading (unfortunately or not, Chrome is the only browser that supports SharedArrayBuffer, others have disabled it).

I suggest you look up why they disabled it. And that is still not an application of WebWorkers! It would be much more helpful to the cause if you could point to some actually used app out there principally relying on WebWorkers. Until then, it's been a lot of pain, zero gain.

a bit niche, but here's one of my projects - svgnest.com

in addition to the render blocking issue brought up by this article, there are a lot of applications for cpu-bound web apps (eg. anything requiring machine learning or computer vision), but in my experience web workers are not very reliable for this purpose.

Re: When to use web workers

#83

Post by apatheticonion »

bufferoverflow wrote: post #36
kbumsik wrote: post #27

My experience with Web Workers was terrible. It's not because of the Web Workers itself but there is no proper standard way to use modules inside of the worker. Because it requires a separated .js file to instantiate, bundlers like webpack tend to introduce weird and non-standard way to work with [1]. It is usually fine when you use it your own project since you are going to stick with a bundler you choose anyway, bu…

Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... });

This is actually similar to how it's done in Go Imagine you define a function:

   func hello(value string) {
      // compute heavy stuff
   }
To run it sync

    hello("World")
To run it async, just add 'go'

    go hello("World")
IMO when it has generics, it'll be the best language I have worked with.

Re: When to use web workers

#84

Post by millstone »

rl3 wrote: post #75
bufferoverflow wrote: post #36

Earlier quoted context omitted.

Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... });

> Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... }); In 2015 I worked on a framework that functioned like this as a personal project. It was even context-aware and spun itself up differently depending on the environment it was in; workers and shared workers loaded the same .js file that the UI thread did. As such, it chose speed…

But wasm isn’t asynchronous right? It still blocks the main thread.

Re: When to use web workers

#85

Post by vincentriemer »

FWIW I believe that web worker adoption is more limited by tooling/knowledge than APIs. Web developers haven't thought about thread safety for decades (at least for those who have been around for that long) so it's more of a mental leap for web developers to think in terms of multiple threads.

I had some promising (at the very least interesting) results with react-native-dom which runs all of React's reconciliation & your own business logic in a web worker: https://rndom-movie-demo.now.sh. I'll fully admit there's a lot more exploration/experimentation left to be done in this space though.

Re: When to use web workers

#87

Post by acjohnson55 »

vincentriemer wrote: post #85

FWIW I believe that web worker adoption is more limited by tooling/knowledge than APIs. Web developers haven't thought about thread safety for decades (at least for those who have been around for that long) so it's more of a mental leap for web developers to think in terms of multiple threads. I had some promising (at the very least interesting) results with react-native-dom which runs all of React's reconciliation &…

One correction: I don't think thread safety is the issue at all. First of all, existing Javascript may not have parallelism in user code, but it does have concurrency. This means you absolutely have to deal with race conditions and resource sharing. Secondly, web workers can't access the mutable state in parallel, because they can only share data via message passing of copied data. This is what prevents thread safety from being a concern, while still enabling parallelism.

Re: When to use web workers

#88

Post by wbl »

TeMPOraL wrote: post #61
ska wrote: post #55

Earlier quoted context omitted.

they're just as likely to use a different site instead. just as likely, or more likely?

Depends on the site. In some cases, less likely. E.g. at this point in time, Facebook or YouTube or even Slack could make a browser change demand with little to no consequences.

YouTube would get the antitrust hammer thrown at it. Probably same with Facebook.

Re: When to use web workers

#89

Post by kbumsik »

moron4hire wrote: post #60
kbumsik wrote: post #27

My experience with Web Workers was terrible. It's not because of the Web Workers itself but there is no proper standard way to use modules inside of the worker. Because it requires a separated .js file to instantiate, bundlers like webpack tend to introduce weird and non-standard way to work with [1]. It is usually fine when you use it your own project since you are going to stick with a bundler you choose anyway, bu…

I did a thing where I used data URIs instead of explicit files to load up web workers. Don't know if that still works, as this was a few years ago, but it definitely helped a lot with those sorts of issues at the time.

Yes, it is still one way to workaround the problem. For those who don't know:

  function workerFn() { ...Do worker stuff }

  let worker = new Worker(URL.createObjectURL(new Blob(['('+workerFn.toString()+')()'])));
Though this hack works but it still have problems to be addressed:

1. It still does not resolve import/require(). This introduces another hack that dumping output of a bundler to workerFn.

2. It will make it much harder to debug since you create worker out of data, not source code.

Re: When to use web workers

#90

Post by ljoshua »

troxwalt wrote: post #80

Not related to the article, but the design and css styling of the blog is really interesting. Makes use of CSS variables as well as a couple properties that I've never seen before. (--mask, font-variation-settings)

The --mask is probably a CSS variable.
Post reply on HN