Re: Mutation events replacement

On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 07/20/2011 06:46 PM, Jonas Sicking wrote:
>
>  Hence I'm leaning towards using the almost-asynchronous proposal for
>>>> now. If we end up getting the feedback from people that use mutation
>>>> events today that they won't be able to solve the same use cases, then
>>>> we can consider using the synchronous notifications. However I think
>>>> that it would be beneficial to try to go almost-async for now.
>>>>
>>>
>>> I disagree.
>>>
>>
>> I had hoped for a bit more of an explanation than that ;-)
>>
>> Such as why do you not think that synchronous events will be a problem
>> for web developers just like they have been for us?
>>
>
>
> In practice synchronous events have been a problem to us because we
> are in C++, which is unsafe language. Web devs use JS.
>

In many cases, where you would have had a crash in C++, you would have a bug
and/or exception in JS. It's for exactly the same reason. Your code cannot
make assumptions about the state of the DOM because other code may have run
that changes it out from under you. A contrived example:

var firstChild = node.firstChild;
node.appendChild(randomNode); // Some mutation handler runs here that
removes firstChild from the DOM.
alert(firstChild.parentNode.innerHTML); // An exception gets thrown because
firstChild.parentNode is now null.

You can easily imagine more complicated examples that you would easily hit
in the real world if there are multiple libraries acting on the same DOM.


> Web devs usually want something synchronous, like sync XHR
> (sync XHR has other problems not related to mutation handling).
> Synchronous is easier to understand.
>
>
> -Olli
>
>
>
>
>> / Jonas
>>
>>
>>
>
>