Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webworker experiment idea #22

Open
yoshuawuyts opened this issue Jun 2, 2016 · 3 comments
Open

webworker experiment idea #22

yoshuawuyts opened this issue Jun 2, 2016 · 3 comments
Labels

Comments

@yoshuawuyts
Copy link
Collaborator

yoshuawuyts commented Jun 2, 2016

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?

@jamesplease
Copy link

@tbranyen has spent a good bit of time thinking about this exact problem in his DiffHTML vdom implementation. Anyone interested in this problem might want to consider talking to him / looking over there for inspiration.

@tbranyen
Copy link

tbranyen commented Jun 2, 2016

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.

@shama shama added the question label Jun 2, 2016
@colingourlay
Copy link

colingourlay commented Jun 7, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants