I would say Animation Worklets are the workers that will make an impact on delivering multithreaded UIs in web.
When to use web workers
31–40 of 110 posts
Re: When to use web workers
#32Re: When to use web workers
#33Earlier 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.
So, your understanding is basically correct.
(I'm the tech lead for Cloudflare Workers.)
Re: When to use web workers
#34As 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
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
#35My 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…
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.
Re: When to use web workers
#36My 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…
new Worker(function(params) {
... compute heavy stuff here ...
});Re: When to use web workers
#37Earlier 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?
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
#38My 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 ... });
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
Re: When to use web workers
#39My 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
#40My 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 ... });