An inside look at Quantum DOM Scheduling | Hacker News Reader

An inside look at Quantum DOM Scheduling

hacks.mozilla.org

98 pointsjanober18 comments

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"

I always got that feeling, disappointed to see it's a reality.

I've been writing lots of things in plain old JavaScript for the last few years, and it's quite pleasant. With a little bit of attention to serialization constraints I manage not to hit any performance issues even for nasty things like lazy loaded tables.

I don't buy it. Wouldn't those frameworks hugely benefit from having atomic DOM operations? It seems like it would not only increase performance (almost for free), but could also potentially cut down on the amount of work their engines have to do to reduce the number of DOM manipulations they do.

>Wouldn't those frameworks hugely benefit from having atomic DOM operations?

They will, and it seems that this does not bode with authors whose employment/sponsorship/grants depends on solving that problem and providing their variant of peg leg solution for it

I don't think this is correct. Engineers smart enough to work on DOM abstractions are good enough to be able to work on other important things.

I'm smart enough to be a doctor but I really like what I do and don't want to go through residency.

This is more like someone who is already a doctor switching sub-specialisations.

Are you talking about async DOM APIs? Because I'm pretty sure framework authors have been explicitly asking for that.

Yes, certainly they did, but it all ended up with 3 different standards, none of which was adopted by any browser. It was at around time browsermakers were holding non-stop talkshops over long promised native fragment/template loading that was never implemented (XMLDocument.Load() and others)

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.

I would love to see a standardised `element.transformChildrenTo(newChildren)` or some such. Also, a built in elem` string handler function ` that can allow interpolation of other elements, arrays of elements, or objects for attributes.

That would allow you to do nearly all of what react does without any external libraries and a very small amount of code.

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

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

That really makes no sense. What is this, the BigJavascript cabal keeping back browser progress so a few guys can make some meager donation money?

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?

https://community.oracle.com/blogs/kgh/2004/10/19/multithrea...

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

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.

Reply on news.ycombinator.com