Preact rendering in a web worker

Re:Preact rendering in a web worker by developit on Monday December 05, 2016 @01:09PM (#13107652)

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.

[ Parent | on HN ]

Re:Preact rendering in a web worker by ponyous on Monday December 05, 2016 @01:46PM (#13108047)

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

[ Parent | on HN ]

Re:Preact rendering in a web worker by developit on Monday December 05, 2016 @03:28PM (#13109143)

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.

[ Parent | on HN ]

Re:Preact rendering in a web worker by axemclion on Monday December 05, 2016 @03:39PM (#13109265)

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.

[ Parent | on HN ]