Process expensive and UI-blocking tasks in a separate thread using useWorker. As we all know, Javascript is a single-threaded language. So, if we ...
For further actions, you may consider blocking this person and/or reporting abuse
Nilanth on February 03, 2023
For further actions, you may consider blocking this person and/or reporting abuse
I'd also add a communication overhead as one of the limitations of useWorker, because communication between the main thread and the worker thread can be slow, so it's important to be mindful of the amount and frequency of communication.
In general, I really enjoyed reading this post! Thanks a lot Nilanth for such an informative content ☺️
When working with WebWorkers I would recommend using Comlink: github.com/GoogleChromeLabs/comlink . This library makes WebWorkers, iFrames and co. much more enjoyable, flexible and on top it's only 1.1kb of additional package size.
Wow, this is a fantastic article! I love how you've explained the concept of Web Workers and how it can be used to perform expensive tasks in a separate thread without blocking the UI. The use of the useWorker library to simplify the configuration of web workers is particularly impressive. The comparison between the use of the plain JavaScript worker and useWorker in React apps is very clear and easy to understand. I can't wait to try out useWorker in my next project! Thank you for sharing this valuable information!
Thanks for sharing
Love this explanation of how to use web workers with React, very concise!
Wow! I didn't know someone can do that. Thanks for sharing it 😁
Great article, you got my follow, keep writing!
Thanks for sharing
@mariamarsh one thing to note, is that this library does use transferable objects for things like ArrayBuffer, OffScreenCanvas, ImageBitmap, etc. This means the main thread transfers ownership of the object to the worker thread so the overhead is almost non existent (no serialization/deserialization is needed). This also means that you cannot access the object you passed in while the worker is processing it.
github.com/alewin/useWorker/blob/m...
For any other type of objects the overhead is very real, like passing a large JSON (had to deal with this myself). This is why the demo conveniently uses an array of numbers 🙂
Great point!
One thing Web Workers can't do is access the DOM. You had made references in your article on how Web Workers can help with rendering large tables, if they're returning DOM elements this isn't possible.
You can also check the number of cores via hardware conecurrency to check whether it pays off spawning workers - single-core CPUs might not be able to run more than one thread
React Native is single-threaded in nature. In its rendering process, rather than have multiple processes occur at the same time (multithreading), other components have to wait when one component is being rendered.
Even if you are in learning stage or you are a Js pro, you are always learning new things day by day. I didn't know this. Thanks for sharing.
WebWorker is great tool but I'm not sold for useWorker. It might be my misunderstanding, but it looks like the worker code is kept in the main bundle.
Nice post...
What about async/promises stuff?
wow, it's so good
Haven't had to use them yet, but if it becomes a necessity I'll definitely check out this new package. Good stuff!
Nice content, thanks.