- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 Nov 2014 18:38:06 +0000
- To: public-webapps-bugzilla@w3.org
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