Hacker News Reader

Comment by aasasd | Hacker News Reader

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.

View on HN

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.

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...

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... . Would be interesting to try updating that.

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.

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.

https://github.com/guess-js/guess

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.

> 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.

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.

It's for guaranteed responsiveness

Angular can do this out of the box https://blog.angularindepth.com/angular-with-web-workers-ste...

Reply on news.ycombinator.com