Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

github.com

Post reply on HN
Print view View original

61–62 of 62 posts

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#61

Post by nitwit005 »

Shog9 wrote: post #33
nitwit005 wrote: post #14

Earlier quoted context omitted.

There's a lot of tricks you can try, but even rendering the first set of visible rows can take more than a 60fps time window will allow.

Don't pick a fixed value for the batch size; render until your time is exhausted and then wait for the next batch. Yes, this'll be slower overall, but you ensure that the app stays responsive regardless of device or CPU availability.

That seems like it would cause a lot of shifting content as the table gets repeatedly resized due to adding rows.

The only way I see that working out nicely is if you can know the height of the table in advance, which is generally not the case.

Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker

#62

Post by EB66 »

codedokode wrote: post #47
EB66 wrote: post #13

Earlier quoted context omitted.

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.

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.

Post reply on HN