[btdiehr]

Cool! What kind of performance gain does one get by computing the DOM Diffs in a web worker? My understanding is because webworkers you do not have access to the DOM, you still have a single thread doing all the rendering (main thread).

[developit]

The theory is that if the diff were sufficiently expensive on its own (it's generally not), that cost is offloaded. There may be gains to be made by moving most of the application code out of the UI thread (less memory usage in that thread, etc).

In this demo, all the UI thread is doing is receiving batches of small instructions to update the DOM. Stuff like "change the text content of element #12" (all elements get assigned an ID).

That said, this is just an experiment. I wanted to get a real sense of whether threading was something we should care about for DOM manipulation.

[ponyous]

What is the conclusion? Should we care about threading for dom manipulation?

[developit]

So far, for the use-cases I can think of, it's probably not worth it. Serialization and thread overhead outweigh any benefit. There are definitely better use-cases for workers than VDOM.

[axemclion]

The performance difference is noticable. I did React into a Web worker, and here are the performance results - http://blog.nparashuram.com/2016/02/using-webworkers-to-make...

Some of the other uses typically are - sort of flow control between the thread and the worker, so that only sufficient VDOM operations are sent across the thread.

This basically leaves the UI thread to other things like GIF animations, redraw UI like buttons when user interacts with them, etc.