WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
1–10 of 62 posts
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#2So if I'm reading it right, it looks like it's trying to replicate the DOM interface almost exactly (but in a web worker)! Which means that any UI library should be able to plug into this system and run mostly off the main thread for most of the application's life, bringing JS to parity with a lot of "native" development where you do most of your work on a "main" thread, and only touch the UI thread when you want to do UI things!
It also reads like it might have some kind of virtual-dom implementation to kind of optimize the actual renders needed in the UI thread? (although I'm not very sure about this part).
But this looks incredible from a first glance!
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#3So if I'm reading it right, it looks like it's trying to replicate the DOM interface almost exactly (but in a web worker)! Which means that any UI library should be able to plug into this system and run mostly off the main thread for most of the application's life, bringing JS to parity with a lot of "native" development where you do most of your work on a "main" thread, and only touch the UI thread when you want to…
doesn't the added vdom lead to redundancy?
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#4WebWorkers: Same great JavaScript, now with concurrency bugs!
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#5What are the performance implications of this? Does the proxy employ a VDOM cache? How does this compare to running the DOM manipulations natively inside the main thread?
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#6WebWorkers: Same great JavaScript, now with concurrency bugs!
Just treat a web worker like you would a remote REST API.
Except it’s actually local, and shouldn’t deal with sensitive data.
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#7So if I'm reading it right, it looks like it's trying to replicate the DOM interface almost exactly (but in a web worker)! Which means that any UI library should be able to plug into this system and run mostly off the main thread for most of the application's life, bringing JS to parity with a lot of "native" development where you do most of your work on a "main" thread, and only touch the UI thread when you want to…
[deleted]
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#8Unfortunately, in my current app, the actual issuing of DOM updates seems to be what's blocking things. Inserting large tables takes some time.
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#9If this is exposing DOM operations in a Worker and then replicating them back to the real DOM in the main thread, what happens if 2 Workers try to make incompatible changes to the DOM at the same time?
Re: WorkerDom – The Same DOM API and Frameworks You Know, but in a Web Worker
#10I 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.