Hacker News Reader

Comment by Klathmon | Hacker News Reader

So 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!

View on HN

doesn't the added vdom lead to redundancy?

React, Vue and other modern frontend frameworks already rely on a vdom implementation.

That's what I meant with redundancy.

I see. Well, I was thinking this project might evolve in a direction that React etc can offload VDOM computations to a worker thread.

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 this case makes a meaningful difference by allowing the thread to get more work done in a shorter amount of time.

If you, for instance, blew away the whole DOM and re-rendered it (e.g., setting `innerHTML`) on every state change, the cost is going to be far higher than just tweaking the few things that might need tweaking, like on a keypress. If you're not keeping a virtual DOM around, there's no way to know what the diff is between your new and previous state to be able to make those tweaks.

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.

Reading and writing is not slow, but your queries. If you don't cache or optimise your queries then any operation is going to be slow. With a VDOM you are just exchanging queries for cached DOM objects, but if you don't optimise your updates on such they are bound to be slow as any other. Also, a VDOM is immutable and prone to garbage.

Reply on news.ycombinator.com