Preact rendering in a web worker | Hacker News Reader

Preact rendering in a web worker

preact-worker-demo.surge.sh

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.

What is the conclusion? Should we care about threading 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.

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.

Source code?

Don't think source is available for this, but if I'm not mistaken you can see webworkers being used on the https://preactjs.com/ website. It uses webworkers in the repl examples and the source of the site is online (https://github.com/developit/preact-www/blob/master/src/comp...)

Context?

Preact Issue #417 - Do virtual DOM diffing on web worker? [1]

[1] https://github.com/developit/preact/issues/417

Preact is a thinner alternative to React. https://preactjs.com/

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

I did something similar for React - and here is a blog post about what exactly is happening - http://blog.nparashuram.com/2016/02/using-webworkers-to-make...

Preact is fine..

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..

Not necessarily impractical - what about Electron desktop apps and mobile webview-based ones?

Exactly my use case[1]. Switching from React was trivial, and the performance increase was really noticeable.

[1]http://pascalopitz.github.io/unoffical-sonos-controller-for-...

gah this makes me want a sonos

That is untrue. There are currently two small test failures in IE on master, hence the graph. The library supports IE9+.

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...

You should probably look at the test before making firm opinions on the matter. Do you even know what is failing?

Master is not production. The last release had all tests passing. https://travis-ci.org/developit/preact/builds/180853866

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.

Reply on news.ycombinator.com