Question

I’m working on a completely ajax web project where a section content is always generated through DOM manipulation or using jQuery’s load function. I had been using "live" but am very interested in moving away from "live" and using "on" for performance benefits. When a new page loads a whole new set of bindings required for that section also need to get loaded. The html sections have some parent DOMs (basically wrappers for different content areas of the web page) that never change allowing me to do bindings on them for all future DOM elements that will be created on the page.

In terms of memory and performance trade off which is generally the better way to handle event bindings?

1. After a new section has finished loading its html, bind all the events needed for that specific page instance on DOM elements that will be removed when a page changes.

2. Bind every event on the very first page load to DOM elements (not to the document though like live does) that are known to always exist.

Answer 1

Memory issues with listeners can usually be dealt with fairly easily (don’t hold large chunks of data in closures, don’t create circular references, use delegation, etc.).

“Live” just uses delegation (as far as I know) – you can implement delegation quite simply without it using simple criteria, e.g. class or id, with listeners on the unchanging parent elements. Delegation is a good strategy where it replaces numerous other listeners, the content is constantly being changed and identifying elements that should call functions is simple.

If you follow a strategy of attaching numerous new listeners every time content changes, you also have to detach the old ones when they are replaced as a strategy to reduce the likelihood of memory leaks. Performance (in terms of time taken to attach and remove listeners as part of the DOM update) usually isn’t that much of an issue unless you are doing hundreds of them.

With delegation, a parent element listens for events, checks if the event.target/srcElement is one it cares about for that event, then calls the appropriate function perhaps using call to set the value of this if required.

Note that you can also simply include inline listeners in the inserted HTML, then you never need to worry about memory leaks, delegation or adding and removing listeners. Inline listeners using a simple function call are no more complex than adding any other attribute (class, id, whatever) and require zero extra programming on the client. I don’t think inline listeners were ever an issue for memory leaks.

Of course the “unobtrusive javascript” mob will howl, but they are very practical, functional and robust, not to mention supported by every browser that ever supported javascript.