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.
Are you recommending an app imposed rendering timer (say 15ms) or is there an in built API for Opportunistic scheduling of Dom updates?
You might want to check out this thread from last week[0] about scheduling tasks when the event loop is idle. The author also published a library for it[1]
No, in fact it's likely very beneficial. Virtual DOM is meant to avoid the overhead of interacting with the real DOM (reading and writing to the DOM is slow). Being inside a web worker means that you're still interacting through the DOM, just via a web worker now. So the cost of reading and writing to and from the DOM is still present, plus there's the added overhead of communicating with the UI thread. So vdom in th…
I know how VDOMs work. But the WorkerDOM has an extra one to the one current frameworks bring.
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 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.
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.
No, in fact it's likely very beneficial. Virtual DOM is meant to avoid the overhead of interacting with the real DOM (reading and writing to the DOM is slow). Being inside a web worker means that you're still interacting through the DOM, just via a web worker now. So the cost of reading and writing to and from the DOM is still present, plus there's the added overhead of communicating with the UI thread. So vdom in th…
I know how VDOMs work. But the WorkerDOM has an extra one to the one current frameworks bring. So now there are two VDOMs
WorkerDOM has a DOM representation, but I wouldn't call it a "virtual DOM". It's just propagating mutations back and forth. It wouldn't, for instance, have the ability to reorder nodes in a list in linear time (like React does with the key={} prop). When a change takes place, it's not diffing anything, it's just mapping one representation of the DOM onto another. If you set innerHTML in the worker, it would set innerHTML in the main thread also.
I worked on a similar project a few years ago: https://github.com/canjs/worker-render . It could render jQuery apps in a web worker, it was pretty neat. The problems I ran into, and I suspect this project will run into many of the same things were: 1. Events are synchronous so to make them async you have to preventDefault them, send to the worker, and then send back and re-dispatch them (if the worker didn't preventD…
When I decided to take a stab at something similar, I settled on a different approach in taking an existing asynchronous UI architecture, React Native, instead of just trying to proxy the DOM: https://github.com/vincentriemer/react-native-dom
I think it works better because the original framework wrestles with the same limitations you mention (though an upcoming rearchitecture doesn't), and while it is by no means perfect, some early results are promising: https://rndom-movie-demo.now.sh
my only concern with this is...with a web worker, my understanding was that any dependencies to the web worker would be loaded separately from the actual UI thread, which means you could potentially be loading your javascript twice if you have the same code being used in the UI thread as your web worker thread.
Serious question: Could not a similar thing be implemented by running the "main thread" in an iframe using the browser's own DOM and the postMessage API? It might lack the optimizations of a virtual DOM, but would probably require a lot less code to achieve.
WebWorkers: Same great JavaScript, now with concurrency bugs!
There's no shared memory between WebWorkers and the main thread. Communication happens through message passing, and zero-copy messages are also available.