Live data from Hacker News

When to use web workers

dassur.ma

31–40 of 110 posts

Re: When to use web workers

#31
As a UI developer i want to move scrolling and style updates out of main thread. Every WebWorker tutorial is taking about how a “computationally heavy task” can go out of main thread. But rarely anyone does computation in the client.

I would say Animation Worklets are the workers that will make an impact on delivering multithreaded UIs in web.

https://www.chromestatus.com/feature/5762982487261184

Re: When to use web workers

#32

Earlier quoted context omitted.

Sorry I meant proxx.app

Ah, no Svelte was around, but we were on a pretty tight deadline and had a good amount of experience with Preact in the team. We didn’t feel comfortable increasing the risk by using an unknown framework.

Got it. Thanks!

Re: When to use web workers

#33

Earlier quoted context omitted.

Despite the similar naming, "Web Workers" is a specific browser API that has nothing to do with "the edge" or any server-side thing.

Point is well taken. I have not tried cloudflare workers yet. It seemed like at least the architecture was the same. But I guess you would not have access to the full browser API. It seems like you can still play around with request / response side of things though.

Cloudflare Workers is so-named because it uses the same API as Service Workers, which are one kind of Web Worker. That said, Cloudflare Workers currently implements only a subset of the APIs that are normally available in the browser, though missing APIs are being added all the time.

So, your understanding is basically correct.

(I'm the tech lead for Cloudflare Workers.)

Re: When to use web workers

#34
post #31

As a UI developer i want to move scrolling and style updates out of main thread. Every WebWorker tutorial is taking about how a “computationally heavy task” can go out of main thread. But rarely anyone does computation in the client. I would say Animation Worklets are the workers that will make an impact on delivering multithreaded UIs in web. https://www.chromestatus.com/feature/5762982487261184

Yes, that’s exactly what AnimationWorklet is for.

That being said, I think even smaller-scale things like state management and hitting APIs should be moved to workers. It all increases resilience and buys headroom for low-end phones.

Re: When to use web workers

#35
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…

Agreed. I am quite annoyed that no browser has shipped modules in workers. There is little incentive as Workers are sorely underused.

Since I mostly use rollup, I ended up writing a plugin[1] that allows you to pretend that modules are in workers. It compiles down to AMD under the hood and uses a very minimalistic worker.

[1]: https://github.com/surma/rollup-plugin-loadz0r

Re: When to use web workers

#36
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 ...
    });

Re: When to use web workers

#37

Earlier quoted context omitted.

I never claimed that Web Workers are the silver bullet that will absolve us from all our problems. On the contrary, I don’t think such a silver bullet will ever exist. I am saying that we should be using web workers to keep the main thread free. That is completely orthogonal to good static design, proper bundling, right caching headers, code splitting, asset hashing etc etc.

I agree with you on keeping the main thread free. What are your thoughts on WASM via workers?

We are using loads of Wasm in Workers in https://squoosh.app

Since Wasm is synchronous, I’d say it should almost always be run in workers except if the module needs access to some main-thread-only API.

Re: When to use web workers

#38
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 ... });

The problem is mostly in that all these functions are closures, and scope can’t easily be transferred.

Domenic and I have been working on a proposal[1] called Blöcks to introduce transferable functions to JavaScript.

In the meantime, I wrote Clooney[2] ontop of Comlink[3] that gives you almost that.

[1]: https://github.com/domenic/proposal-blocks

[2]: https://github.com/GoogleChromeLabs/clooney

[3]: https://github.com/GoogleChromeLabs/comlink

Re: When to use web workers

#39
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 ... });

I don't actually know the answer, but my guess would be it's because of scoping. Web workers aren't a language level feature, so they can't really dictate that the function body can't have access to the outer scope which functions in JS typically do. And if worker functions like that would have access, how do you ensure thread safety? Making it so you have to point to a different module altogether seems like a decent way to enforce that boundary.

Re: When to use web workers

#40
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 ... });

[deleted]
Post reply on HN