Re: DOM: innerSmartHTML proposal

Hi David,

Thanks for answering.


On Wed, Jul 2, 2014 at 12:03 PM, David Bruant <bruant.d@gmail.com> wrote:

>  Hi,
>
> What is the use case that motivates this change?
> Is there a particular example that would significantly benefit from this
> change?
>
>
Imagine you want to change classes, add some attributes, add new DOM nodes
and remove several old ones, all at the same time. With 'innerSmartHTML'
you could see the new state of the DOM at once, it's basically right there
in front of you and you don't need to read through all the DOM
modifications to understand what is really happening. Also, your existing
event listeners are still there.


> 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.
>

1. diff changes, probably using intermediate objects that only have an
element name and attributes (like the ReactJS Virtual DOM has too). So
nothing related to the actual DOM just yet.
2. from these diff changes a list of "real" DOM changes should emerge
3. apply DOM changes
4. possibly hold on to diff objects for next possible change


> 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.
>

Of course there will be a small penalty compared to doing it yourself, as
the diffing needs to happen. The main advantage is reducing complexity, and
eventually cause less issues compared to manually modifying the DOM.

>
>    - 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.
>
>
Yeah, let's leave this one out. In my view it would be wiser to have a
toggle that aggregates all DOM modifications and perform them at once at
the ideal time, instead of tying it with 'innerSmartHTML'. However that is
something for a different time, but would be great.


>
>
>
> 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".
>

It's not the same, like I said: it only changes what has been really
changed instead of what innerHTML does: remove everything, create
everything, attached javascript is holding on to the old objects.


>
> David
>
> [1] http://facebook.github.io/react/docs/reconciliation.html
>

If anything isn't clear, please let me know.

Cheers,

Sander