- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 02 Jul 2014 11:03:07 +0100
- To: Sander Spies <sandermail@gmail.com>, www-dom@w3.org
- Message-ID: <53B3D8DB.1070001@gmail.com>
Hi, What is the use case that motivates this change? Is there a particular example that would significantly benefit from this change? Le 01/07/2014 21:59, Sander Spies a écrit : > The idea is to create a property, which I will call 'innerSmartHTML' > for now, that shares some characteristics with innerHTML, but with > some differences: > > * Only change what has really changed (like the ReactJS virtual DOM > does) > --- > So if I have node.innerHTML = "<div><b class="x">something</b></div>"; > > and after that say node.innerSmartHTML = "<div><b class="x > y">something</b></div>" > > Only the class of b should have been modified, instead of > recreating everything as innerHTML does. Of course, adding and > removing nodes should also be supported. What is the "smart" diffing algorithm? It's important that you take the time to explain it, otherwise, I don't think browser vendors will be convinced to implement it. React Tree diffing algorithm [1] has a worst case complexity of O(n³) (with trade-offs explained at the end to justify a pragmatic choice as far as developers are concerned). Browsers implementors are already extremely reluctant to implement any O(n²) algorithm, if you're proposing something equivalent to React, I don't think this is going to fly. I'm also not entirely convinced the performance will actually be that much better. > * perform rendering during requestAnimationFrame > --- > aggregate all changes to perform them at once, instead of > immediately. I understand this will be challenging to do with the > current DOM methods in place, but I'm hopeful we can find > something that works within the current boundaries of the DOM. > I'm afraid you're going to have to give something more concrete than "I'm hopeful we can find something that works". This is a topic that is in implementors mind for some time. They are hopeful that something that works can be found too, I hear. But given the amount of smart folks thinking of this, I'm afraid the current constraints make almost impossible for a simple solution to be found. > Why do I think this is an interesting idea? Because it significantly > simplifies working with the DOM. I don't understand why it would simplify working with the DOM. You can replace innerSmartHTML with innerHTML and you have the current situation. I don't see the improvement in "developer ergonomics". David [1] http://facebook.github.io/react/docs/reconciliation.html
Received on Wednesday, 2 July 2014 10:03:42 UTC