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

Post by eridius » Tue, Oct 02, 2018, 5:28 AM UTC

mygo wrote: post #35

eridius wrote: post #18

Earlier quoted context omitted.

Yes I know. Which is why I asked what happens if two Workers try to make incompatible changes at the same time. How does this library resolve conflicts when applying the changes from the fake DOM to the real one? In fact, this doesn't even require 2 Workers, you could get a conflict with a single Worker if you're also making DOM changes on the main thread.

This is like asking what happens if two different micro-services try to make incompatible changes to the same database. Or what happens when two different users try to make incompatible changes to the same Google Doc? Or what happens when you try to GIT Merge a commit that has incompatible changes? It’s your code, so it’s in your control what happens, and also in your control how to react to what you can’t control. Y…

Post by mirko22 » Tue, Oct 02, 2018, 6:10 AM UTC

Buttons840 wrote: post #22

thrower123 wrote: post #20

Wow, the contortions we go through trying to make HTML into a full-blown native application platform, instead of writing native applications. I'm impressed, but good god do we spend a lot of time reinventing the wheel within the limitations of browser engines.

You're probably right, but there are no alternates, so people build what they want with what's available. I'm no expert in native or web development, but I don't know of any native GUI framework that looks as good as browser rendering does, is free, is easy to distribute, and secure.

Post by codedokode » Tue, Oct 02, 2018, 6:15 AM UTC

Post by codedokode » Tue, Oct 02, 2018, 6:16 AM UTC

EB66 wrote: post #13

aasasd wrote: post #10

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.

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.

Post by writepub » Tue, Oct 02, 2018, 6:34 AM UTC

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.