webworker experiment idea
yoshuawuyts opened this issue · comments
I'm a bit constrained on time, so posting it here if anyone wants to dabble in some mad science.
virtual-dom can be rendered safely in a WebWorker because it produces a patch that is serializable as a string. yo-yo creates DOM nodes through require('global') that are diffed against the DOM. Webworkers only allow messages to be passed that can be parsed by the structured clone algorithm.
Now the experiment would be: can we create a DOM tree / diff from within a webworker, and apply it on the DOM in the main thread? Do we need an intermediary state or do require('global') nodes work for that? Also: what are the perf implications if we manage to get it to work?
I removed it from diffHTML since I was doing object pooling and it's not possible to do a shared pool. I also had a lot of hacks in place to shared as much of the code as possible, which influenced the code in a negative way. I'm still very interested in applications that utilize workers effectively.
Since diffHTML does not produce an exposable set of patches like virtual-dom, it won't be easily possible to put into a worker unless it's baked in. I'm pretty sure yo-yo works the same way by abstracting the array of patches.
I found that performance was greatly improved, but not simple FPS checks, but jankiness and usability of a heavy page when scrolling.
This is exactly what duet-virtual-dom is doing. It uses a vdom-serialized-patch for serializing and re-inflating VDOMs, with events facilitated between a registry in the worker and a global listener in the main thread. Its event handling performance is managed by constantly listening/unlistening to event types as references to them are present in the VDOM.
Here's a TodoMVC running on this package (amongst other things): http://duet-todomvc.surge.sh/
And the source: https://github.com/colingourlay/todomvc/tree/master/examples/duet/src