Why use Mutationobserver instead of Mutation Events?

Question

Well the title is the question itself, I know it’s because the Mutation Events will not be continued further, but:

• What is the difference between one and the other (not how to use, but the technical concept)?
• Why the browsers have opted for this change?

Answer 1

In the documentation of MDN about the Mutation Events there is:

The Practical reasons to avoid the Mutation Events are performance issues and cross-browser support.

In the same documentation it is still cited that the performance problem occurs when adding the listeners of DOM mutations, degrading the performance of other mutations in the Dom document, leaving 1.5 to 7 times slower; and further says that by removing the listeners, this degradation continues. Without many details of what motivates the degradation, the link to a mailing list where the problem is discussed.

The support between browsers is due to the non-sconsistency of the implementation of such events. Some examples are cited:

• IE, in versions prior to 9, do not support Mutation Events and its implementation in version 9 was poorly done;
• Webkit does not support DOMAttrModified;
• "Mutation name Events", that is to say, DOMElementNameChanged and DOMAttributeNameChanged are not supported by Firefox;

It is also cited that, to understand the reason for the change, it is recommended to read DOM Mutation Events Replacement: The Story So Far / Existing Points of Consensus, which I will try to translate freely below.

---

DOM Mutation Events Replacement: The Story So Far / Existing Points of Consensus

What follows is an attempt to summarize the recent (2011) discussion on the replacement of DOM Mutation Events.

My goals here are:

• Provide a brief summary for those who have not read all the emails;
• Reiterate the aspects of the solution that seem well supported;
• Identify the main remaining points of divergence;

Problem: DOM Mutation Events are, according to current specification and implementation, widely considered fatally flawed because:

1. Verbose;
2. Slow (due to event propagation and because this prevents some browser optimizations at runtime);
3. "Breakable" (has been the source of many browser crashes because the script can destroy the world the way you want while a DOM operation is underway);

Solution:

Points with great approval

Mainly due to a proposal made by Jonas Sicking in 2009, the group agreed broadly on the following:

1. The vocabulary of mutations should be more expressive and require less "words" to adequately describe what happened. For example, a single assignment innerHTML which results in the removal of N nodes and the insertion of M nodes should be expressed as a single mutation (eg, {mutação: "ChildlistChanged", adicionada: [...], removida: [...]}) - not a sequence of mutations, one for each node inserted or removed;

2. Mutations should avoid the expense of propagating events (mainly catching and bubbling);

3. Mutations should be handed over to observers after the DOM operations that generated them are completed - removing the possibility that the script interfere with the operation. For example, an operation execCommand() is permitted to do any and all necessary FOD operations before must notify any observer of what happened;

In discussing Jonas' proposal, we note that in a system that allows multiple observers who can themselves mutate, observers usually need to be tolerant of an arbitrary number of mutations occurring before they are notified.

In addition, there is a strong performance motivation for observers to respond to the network effect of a set of mutations, rather than acting immediately in response to each mutation.

Therefore:

4. Observers should be called with the set of mutations that has occurred since they were last called (or since the record) rather than being called once per mutation. I mean, deliver batch mutations of "everything that’s happened since the last time I called you - until now";

To my mind, the most recent proposals made by Jonas, Olli Pettay, Adam Klein and I agree on the four design points above.

Points still without consensus

5. When are the mutations delivered? There are four options here, only two of which have proponents (subject of another email);

6. Semantics to express interest in clusters of nodes;

7. What information is contained in the mutation records;

---

As for the points that were not in consensus, I think that they have now been resolved, given that the DOM Mutation Events has already been declared obsolete in favour of Mutationobserver, then I’ll see if I can find part of the discussion or official source that deals with what the agreed terms were.