3 ms·

I don't quite understand how busy your page must be if you feel that you're held back by the performance of one thread with the DOM. You know, DOM isn't really

by aasasd 8y ago

I don't quite understand how busy your page must be if you feel that you're held back by the performance of one thread with the DOM. You know, DOM isn't really for video games or realtime data visualization.

dinedal 8y ago
I think this is more useful from the perspective of, if you have some busy task and you need to get the data back into the DOM, what can you do? You either need to build a messaging layer, which was the defacto way, or use this. I have a few projects that could benefit from this, being able to put a progress bar in the DOM and have the worker update it in a clean API is pretty neat.
- ytpete 8y ago
  Often though, a better pattern for that is to have your "compute thread" not know anything about the UI - it just sends back packets of result data, or serialized model updates, which the view-model layer back in the "UI thread" uses to rerender. If React's virtual DOM diffing is epxensive enough to be a bottleneck in some applications though, I could see an advantage to moving that off thread...
  - acemarke 8y ago
    There's been some experiments with moving React's logic into a web worker, but the main one I know of was a couple years back : http://blog.nparashuram.com/2016/02/using-webworkers-to-make-react-faster.html http://blog.nparashuram.com/2016/02/using-webworkers-to-make... . Would be interesting to try updating that.
- aasasd 8y ago
  I don't see how that's different from having 'cooperative multitasking' in the JS thread unless you are bound by DOM. You have to send data to the UI thread once in a while? Well why can't you let the UI update in the same interruptions? Of course, that will introduce delays, but if they are noticeable to you then maybe you have a DOM tree that's too heavy in the first place? I'm not saying having the lib is bad, but I don't see a justified use-case for it.
EB66 8y ago
I could see this being used in a "pre-fetch" manner for single-page applications. For example, preparing and rendering the next page or component before the user has opened it. So when the user does click to open the next page or component, it can be displayed immediately. The ability to perform that rendering in the background without blocking the main thread would offer some real value.
- OutThisLife 8y ago
  https://github.com/guess-js/guess https://github.com/guess-js/guess
- codedokode 8y ago
  But this will consume CPU and RAM and will make the page user is browsing work slower. Especially for users with low-end hardware. If you use server-side rendering (for example, if you use PHP on your server) then you won't need all of this and pages will load instantly without any complicated preloading.
  - EB66 8y ago
    > But this will consume CPU and RAM and will make the page user is browsing work slower. Not necessarily -- Web Workers enable you to take advantage multiple CPU cores. You could, potentially, offload some of the rendering work to a CPU core that would otherwise go unused. But I agree, if you went to the extreme case, pre-rendered everything the user could click on and utilized all CPU cores, then you'd definitely create a performance problem for yourself.
paulddraper 8y ago
It's for guaranteed responsiveness Angular can do this out of the box https://blog.angularindepth.com/angular-with-web-workers-step-by-step-dc11d5872135 https://blog.angularindepth.com/angular-with-web-workers-ste...
jchw 8y ago
I don't think it's about using the DOM for anything real-time. The unfortunate truth of JavaScript (obviously when not running in a worker) is that it blocks the UI. WorkerDOM appears to be an attempt to allow you to run existing JavaScript without blocking the UI, which seems like a great idea to me.

by aasasd 8y ago

dinedal 8y ago

I think this is more useful from the perspective of, if you have some busy task and you need to get the data back into the DOM, what can you do? You either need to build a messaging layer, which was the defacto way, or use this. I have a few projects that could benefit from this, being able to put a progress bar in the DOM and have the worker update it in a clean API is pretty neat.

ytpete 8y ago
Often though, a better pattern for that is to have your "compute thread" not know anything about the UI - it just sends back packets of result data, or serialized model updates, which the view-model layer back in the "UI thread" uses to rerender. If React's virtual DOM diffing is epxensive enough to be a bottleneck in some applications though, I could see an advantage to moving that off thread...
- acemarke 8y ago
  There's been some experiments with moving React's logic into a web worker, but the main one I know of was a couple years back : http://blog.nparashuram.com/2016/02/using-webworkers-to-make-react-faster.html http://blog.nparashuram.com/2016/02/using-webworkers-to-make... . Would be interesting to try updating that.
aasasd 8y ago
I don't see how that's different from having 'cooperative multitasking' in the JS thread unless you are bound by DOM. You have to send data to the UI thread once in a while? Well why can't you let the UI update in the same interruptions? Of course, that will introduce delays, but if they are noticeable to you then maybe you have a DOM tree that's too heavy in the first place? I'm not saying having the lib is bad, but I don't see a justified use-case for it.

EB66 8y ago

I could see this being used in a "pre-fetch" manner for single-page applications. For example, preparing and rendering the next page or component before the user has opened it. So when the user does click to open the next page or component, it can be displayed immediately. The ability to perform that rendering in the background without blocking the main thread would offer some real value.

OutThisLife 8y ago
https://github.com/guess-js/guess https://github.com/guess-js/guess
codedokode 8y ago
But this will consume CPU and RAM and will make the page user is browsing work slower. Especially for users with low-end hardware. If you use server-side rendering (for example, if you use PHP on your server) then you won't need all of this and pages will load instantly without any complicated preloading.
- EB66 8y ago
  > But this will consume CPU and RAM and will make the page user is browsing work slower. Not necessarily -- Web Workers enable you to take advantage multiple CPU cores. You could, potentially, offload some of the rendering work to a CPU core that would otherwise go unused. But I agree, if you went to the extreme case, pre-rendered everything the user could click on and utilized all CPU cores, then you'd definitely create a performance problem for yourself.

paulddraper 8y ago

It's for guaranteed responsiveness Angular can do this out of the box https://blog.angularindepth.com/angular-with-web-workers-step-by-step-dc11d5872135 https://blog.angularindepth.com/angular-with-web-workers-ste...

jchw 8y ago

I don't think it's about using the DOM for anything real-time. The unfortunate truth of JavaScript (obviously when not running in a worker) is that it blocks the UI. WorkerDOM appears to be an attempt to allow you to run existing JavaScript without blocking the UI, which seems like a great idea to me.