Skip to content
This repository has been archived by the owner on Sep 21, 2022. It is now read-only.

Web Worker Rendering Idea #32

Open
RGBboy opened this issue Apr 5, 2015 · 3 comments
Open

Web Worker Rendering Idea #32

RGBboy opened this issue Apr 5, 2015 · 3 comments

Comments

@RGBboy
Copy link

RGBboy commented Apr 5, 2015

After reading the Angular 2 google doc on rendering architecture
I got thinking about how this could be achieved with React. Wouldn't it be awesome if a web worker could be used for your application logic so the main thread can stay responsive to user interaction? Imagine if you could send a virtual dom diff from a worker to the main thread.

The current problem with this architecture is that a virtual element is not always serializable. This is because we want to be able to attach event handlers to respond to events triggered by a user. These event handlers are not always called with serializable arguments for example DOM elements. What if instead you could describe your event handler in terms of a function and that functions data dependencies? Perhaps something similar to GraphQL. Then just let the main thread send what is required when such an event is triggered. A virtual element could then be serialized and sent over a web worker message channel.

You could take this a step further and take advantage of the diffing process. Only send the diffs of the elements that have changed including the changes in data dependency. When a user triggers an event the Main thread figures out the event and the required data and sends it back to the UI thread.

You could potentially get multiple UI threads sending diffs to the main thread as long as each UI thread owned a given branch of the virtual tree.

Does this sound like something worth exploring? Am I missing something that would stop this from working?

@sebmarkbage
Copy link
Contributor

@axemclion
Copy link

I wrote a custom renderer with web workers, and tried to run some performance tests. Here is the demo page](http://web-perf.github.io/react-worker-dom) and the repo.

I noticed that for applications without too many DOM updates, the cost of postMessage which is used for communication between worker and the UI thread may actually make this solution slower than react-dom. I also noticed that like in ReactNative, batching should be used and selecting the batch size correctly would help.

Here is a more detailed analysis.

@luqin
Copy link

luqin commented Dec 3, 2015

👍

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

No branches or pull requests

4 participants