Thank goodness for Safari's reader mode. This article was unreadable without it. Why do people do this?
When to use web workers
41–50 of 110 posts
Re: When to use web workers
#42As 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
If you haven't seen this before it might interest you. Nolan worked on offloading most of the work to threads to achieve 60 fps on mobile.
http://www.pocketjavascript.com/blog/2015/11/23/introducing-...
Re: When to use web workers
#43Web Workers were added to Firefox ten years ago this month, so they're definitely not new technology. I think this is a great call to action to actually start taking advantage of them.
People have been taking plenty advantage, they are an indispensable tool to turn all of these CPU bugs or DRAM attacks into working browser exploits. Also those bitcoin miners of course.
Maybe if no one else is taking advantage it is time to simply throw them out.
Re: When to use web workers
#44As 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.
Agreed, I’ve always wondered why this isn’t done more often, it seems like the perfect place for tasks such as those.
That being said, I’ve been a web developer for over 5 years and have never actually decided to move tasks to web workers; it’s about time I change that.
I also find it weird when devs complain about the lack of shared state and how it’s some how a limitation. Messaging passing architectures haven proven key for modelling concurrency in many powerful languages and frameworks like Erlang/Elixir and Go channels to name a few.
Anyways thanks for writing this up. Proper breakdown and grouping will have unseen benefits for sure, and in this case, very seen :)
Re: When to use web workers
#45I have a large ClojureScript app (https://partsbox.io/) and I really, really wanted to use WebWorkers. I wanted to run larger tasks like indexing for search, or pricing calculations in WebWorkers.
But it seems to me that Webworkers were designed with an extremely narrow use case in mind. The restrictions placed on them make them essentially useless for me. To do anything ever remotely useful, I would need to duplicate my entire database in web workers, and then communicate with them through a thin straw. Database updates would need to be performed both in the main app database and in web worker threads.
The way they are restricted, I just can't figure out how to make any meaningful use of them.
Re: When to use web workers
#46I have a large ClojureScript app ( https://partsbox.io/ ) and I really, really wanted to use WebWorkers. I wanted to run larger tasks like indexing for search, or pricing calculations in WebWorkers. But it seems to me that Webworkers were designed with an extremely narrow use case in mind. The restrictions placed on them make them essentially useless for me. To do anything ever remotely useful, I would need to duplic…
IndexedDB is shared between workers and main thread, in case that helps.
Re: When to use web workers
#47My 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 don't really publish libraries so I didn't run into your main gripe.
Is there any other reason why you didn't like worker-loader?
I experimented with it and found it pretty straightforward. For anyone who wants to try it, you can even get it working from a create-react-app project with the webpack inline loader syntax without ejecting:
/* eslint import/no-webpack-loader-syntax: "warn" */
import Worker from 'worker-loader!./Worker.js';
Re: When to use web workers
#48I have a large ClojureScript app ( https://partsbox.io/ ) and I really, really wanted to use WebWorkers. I wanted to run larger tasks like indexing for search, or pricing calculations in WebWorkers. But it seems to me that Webworkers were designed with an extremely narrow use case in mind. The restrictions placed on them make them essentially useless for me. To do anything ever remotely useful, I would need to duplic…
IndexedDB is shared between workers and main thread, in case that helps.
Indeed, and it is something I'm looking at. But at the moment my database is really native Clojure data structures, which has fantastic advantages. I would need to start storing them in a "traditional" database, introducing additional layers, serialization, overhead and bugs.
Re: When to use web workers
#49My 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 don't really publish libraries so I didn't run into your main gripe. Is there any other reason why you didn't like worker-loader? I experimented with it and found it pretty straightforward. For anyone who wants to try it, you can even get it working from a create-react-app project with the webpack inline loader syntax without ejecting: /* eslint import/no-webpack-loader-syntax: "warn" */ import Worker from 'worker-…
Would it be possible to draw off screen or canvas somehow? To preserve WebGL compatibility while still using the workers?
Re: When to use web workers
#50Web Workers were added to Firefox ten years ago this month, so they're definitely not new technology. I think this is a great call to action to actually start taking advantage of them.
People have been taking plenty advantage, they are an indispensable tool to turn all of these CPU bugs or DRAM attacks into working browser exploits. Also those bitcoin miners of course. Maybe if no one else is taking advantage it is time to simply throw them out.
“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).