From a quick look, it seems like this demo is using a web worker (i.e. another thread) to chunk up the dom manipulations. There's also some code to prioritise dom elements that are in the viewport.
(As an aside, this submission would be better if it linked to a blog post explaining what's interesting about this, rather than just the demo itself)
Agreed. Someone submitted this before I got around to writing that post, heh. Synopsis: fake DOM in the worker w/ MutationObserver that sends batched changes up to the UI thread. Event delegation to get things back into the worker. It's actually relatively straightforward, demo code is a mess though.
There are a bunch of other complexities too - things like
(1) cancelling events which are synchronous, but web worker communication is async
(2) What is the best serialization format ? I found JSON.stringify to be the fastest, but how to compress data better ?
(3) How to batch the operations when you want to send info over from worker to the UI thread. The batch size should be small enough that it runs in 16ms, but large enough that you don't waste frame cycles.
(4) Figuring out if it makes sense to spawn multiple workers to diff parts of the VDOM tree - similar to React Fiber
Its true then. A failed test on production code means IE isn't supported. If its allowed to go to production with defects for IE, then IE support can't be claimed...
Sure it can. They can just say something like "IE9+ is supported, but features x and y won't work".
There are plenty of libraries that officially support IE, even when there are problems in a few small cases. They usually just make sure these issues are publicized so people won't be surprised them.
There are tests to validate IE support. The intent is clearly there. Circumstantially this design decision is not met, but it is clearly a bug not some fundamental lack of support.
Please consider how your feedback might affect the people giving their effort to offer an option to the community.
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).
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.
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.
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.
24 comments
[ 3.1 ms ] story [ 65.8 ms ] thread[1] https://github.com/developit/preact/issues/417
From a quick look, it seems like this demo is using a web worker (i.e. another thread) to chunk up the dom manipulations. There's also some code to prioritise dom elements that are in the viewport.
(As an aside, this submission would be better if it linked to a blog post explaining what's interesting about this, rather than just the demo itself)
(1) cancelling events which are synchronous, but web worker communication is async
(2) What is the best serialization format ? I found JSON.stringify to be the fastest, but how to compress data better ?
(3) How to batch the operations when you want to send info over from worker to the UI thread. The batch size should be small enough that it runs in 16ms, but large enough that you don't waste frame cycles.
(4) Figuring out if it makes sense to spawn multiple workers to diff parts of the VDOM tree - similar to React Fiber
But... its entirely impractical... it supports NO IE (only edge) ... its easy to make a small, fast lib that doesnt have to handle IE at all..
[1]http://pascalopitz.github.io/unoffical-sonos-controller-for-...
There are plenty of libraries that officially support IE, even when there are problems in a few small cases. They usually just make sure these issues are publicized so people won't be surprised them.
Please consider how your feedback might affect the people giving their effort to offer an option to the community.
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.
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.