
An inside look at Quantum DOM Scheduling - janober
https://hacks.mozilla.org/2017/06/an-inside-look-at-quantum-dom-scheduling/
======
baybal2
I'm still waiting for native delayed rendering solution with transactional and
atomic DOM operations from browsermakers.

In one talk with a Mozilla guy from Vancouver we went over it and it came to
"framework pushers in WHATWG will never agree to that as it obviates the need
in Angular/React/others and their Shadow DOM peg leg workarounds"

~~~
wtetzner
Is that true though? The shadow DOM diffing isn't the point of React. The
point was to turn rendering into a function that takes application state and
returns the view. The shadow DOM diffing stuff is just an implementation
detail that made this model fast enough to be practical.

~~~
JeremyBanks
You're mixing up react's virtual dom with the native shadow dom.

~~~
wtetzner
Yes, sorry, I meant virtual DOM. But other than that, my point still stands.

------
idibidiart
We have SharedArrayBuffer (shared memory-ish) and Atomics (in latest Firefox)
so we have multi-threading in JS (whether it's a good idea or not that's a
completely different story) but we still don't have the ability for multiple
threads to work with the DOM. We need a SharedDOM construct with Atomics.
Well, just because multi-core, right? What am I missing?

~~~
localvoid
[https://community.oracle.com/blogs/kgh/2004/10/19/multithrea...](https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-
toolkits-failed-dream)

------
jnwrd
we need to stop calling things quantum that are not quantum - its confusing

~~~
hrjet
I got confused too.

We can't stop people from naming their projects/products the way they want.
However, I think headlines in HN should be editoralized a bit to provide
context, followed by the actual headline from the webpage.

