We had talked about having some built-in custom events loosely inspired by DOM 
mutation events. For example: rather than having separate events for 
DOMSubtreeModified and DOMNodeInsertedIntoDocument, we'd just fire an 
`element:updated` event after a call to Element#update or Element#insert. Many 
scripts that attach behaviors need to know when content has changed.

(And before you say "just use event delegation," let me give you an example: I 
just finished working on a page where the contents of a PRE element changed 
based on the results of an Ajax request. Whenever the code changed, the 
client-side syntax highlighter needed to re-parse the contents. That's the sort 
of thing I'm talking about.)

We haven't rejected the idea outright, but there are a couple things that have 
kept these events from inclusion by default. First, as Mislav points out, is 
performance. Calls to Element#fire are synchronous, and mutation events would 
obviously need to bubble all the way up to `document`. Also, even in browsers 
that support mutation events natively, we'd want to avoid listening for those 
events. When John Resig wrote Sizzle, he had planned to cache the results of 
selector queries, and listened for DOMSubtreeModified so he'd know when to 
invalidate the cache. Turns out, though, that Firefox doesn't fire mutation 
events until you start listening for them — and when you attach a listener, it 
turns them _all_ on, making every DOM operation much slower. The caching 
worked, but made result retrieval slower than it would have been otherwise.

So we'd likely eschew listening for mutation events altogether and just put 
explicit Element#fire calls in any Element methods that mutated the DOM. But 
that brings me to the other problem: we'd be introducing a leaky abstraction, 
perhaps our leakiest yet. Any script that didn't rely on Prototype's custom 
methods for DOM manipulation wouldn't fire DOM mutation events.

So... that's why custom mutation events have remained on the backlog. If you'd 
like to see this feature in Prototype one-point-whatever, I've a favor to ask: 
write a simple add-on script that wraps Element#update et al., then do some 
heavy before/after benchmarking so we can see what we're up against.

Cheers,
Andrew


On Jan 14, 2010, at 1:20 PM, Mislav Marohnić wrote:

> Firing custom mutation events in every Prototype method that manipulates the 
> DOM could generate significant overhead in performance. Maybe the 
> implementation should be designed in a way that only events that have 
> registered observers are fired. If no observes are created, no custom events 
> are ever fired.
> 
> Question is, will this see much usage? I've only used DOM mutation events in 
> users scripts; i.e. when I wasn't the author of original scripts on the site, 
> but I wanted to react when these scripts changed something on the page.
> 
> If I'm the author of the website, I don't need mutation events — I can add 
> functionality directly among the code that does the updating in the first 
> place.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Prototype: Core" group.
> To post to this group, send email to prototype-core@googlegroups.com
> To unsubscribe from this group, send email to 
> prototype-core-unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/prototype-core?hl=en

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en

Reply via email to