[Bug 27310] Virtual DOM and DOM diff

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27310

Sebastian Markbage <sebastian@calyptus.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebastian@calyptus.eu

--- Comment #5 from Sebastian Markbage <sebastian@calyptus.eu> ---
We (React) currently use innerHTML as a way to automatically create all
elements at once. That's because the JS/DOM bridge seems to high latency
characteristics. That's not inherent to a browser architecture.

If it was fast enough, we could just use document.createElement instead, which
could contain new or existing event handlers too.

If performance of the outer DOM APIs was faster, this wouldn't be an issue.
replaceChild could be fast. Which adresses Leo's concerns.

As vjeux points out, the strategy used for what exactly preserves internal
state is still an unresolved issue. For example, in React, we still don't allow
children to move to a different parent. We also have different semantics for
stateful high-level components. That's still patterns that are still evolving.

The big issue is, as Tab points out, that the hidden state can't be transferred
to another element somehow.

Diffing is inherently only needed when we're targeting an imperative API with
retained state. When we're targeting an API like WebGL or Canvas drawing, we
don't actually use diffing anywhere at all. That is an indication that it's not
actually needed.

We actually just use diffing to hack around the current browser limitations. I
think it would be a big mistake to standardize it. It's actually very
inefficient compared to the ideal solution.

What we really need is a way to either be in full control of internal state.
This can be done, for example, by a callback that provides a new object with
the internal state. We can intercept any publicly accessible state and replace
it with our own. Private state can be transferred from one node to another.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 12 November 2014 18:38:10 UTC