We Keep Coding

Why it is bad practice to register events to document in jQuery?

Whenever I read about event registration in jQuery they all say that we should try to add event handlers to the nearest parent, and avoid adding event listeners to the document, because according to resources they are slow and not efficient.
But why they are slow? Apparently it's because the event will have to bubble up to the document, which will take time. Then it will be compared to a list of selectors to call, e.g.
$(document).on("click", ".abc", function(){ })
$(document).on("click", ".abc2", function(){ })
So here if I click an element, the click event will be bubble up to the document and then it will match the selector list (".abc, .abc2")...and that is inefficient. OK I got it but what if I have only have one selector in the list ? e.g.
$(document).on("click", "*", function(){ })
Will it be slow too ? If so why?
Basically i'm trying to create a google's jsaction similer lib, so I will write like this:-
$(document).on("click", "[jsaction]", function(){ })
Because this will be the only selector, so i don't think it will be slow ? or will it be ?
and if attaching event to document is not efficient, then what about a completely ajax application? my application is completely ajax, and every page will be downloaded by ajax. Is there another, more efficient solution?

Event delegation basically uses 2 different process,
The event bubbling, For example, when you click over an element that
event will be bubbled up to the document to fire the relevant event.
The match, after reaching the document(during event bubbling) the
fellow who caused the event bubbling will be verified with the
selectors attached with document. If it matches then the relevant
event will be fired.
So you are advocating about the match by stating a generic selector. To be frank, matching 2 or 3 elements will take less time than traversing up to the document during event bubbling. At that case if you use a static closest parent instead of document, the traversing time will be reduced and that will hike the performance.
Though match takes less time, when it comes with 15+ elements for matching, that will also affect the performance even when you use closest parent instead of document.
So the summary is, we have to use event delegation sparingly with common sense by knowing the above two different process takes place under the hood.

JQuery trigger event performance on document

I'm building a publish/subscribe framework in jQuery and I'm wondering if there are performance penalties to triggering and listening to events on the document root?
All articles I can find describe the penalty you obviously get for listening to events on the document level, but triggering them from a more specific element - listening for a "click" for example.
My pseudo code:
$(document).on("myCustomEvent", function() {
alert("Event triggered");
});
$(document).trigger("myCustomEvent");
My event does not have a fitting home in the DOM but I could always add a dummy element to trigger from/listen to if it's better, but would rather not. What do you think?

trigger() propagates up the DOM. It also interacts with all elements matching the object, which can cause conflicts / unexpected behavior. Neither of these are inherent* performance hits -- and since you're using a custom event, you shouldn't have an issue with other elements matching the object. That's really only a problem when trigger() is used with a real event, like trigger('click').
If you're concerned about either of these (bubbling up the DOM or other matching elements), you can use triggerHandler()
This post goes into more detail about the differences between trigger() and triggerHandler()

Is there a downside to calling jquery .on(document.body) rather than the specific element

I am upgrading the version of jQuery used in a project to the latest and greatest. The .live function was used in numerous places to change dynamically created display and worked great, but the .live functionality was removed in later versions of jQuery thus necessitating a retool.
As a way of standardizing the coding I am considering calling the function as:
$(document.body).on('click', '#clickableElement', function(){})
rather than
$("#clickableElement').on('click', function(){})
even if the click method will not be performed on a dynamically created object.
Do you see any downfalls to this idea considering it is an internal website, small number of users, and all elements are provided id's.

Event delegation is a recommended pattern because it helps avoid memory leaks that are possible when event handlers are attached to DOM elements that are later removed from the DOM.
It it also faster in most cases where selectors force JS to travel through the DOM tree, identify all matches, and attach a new instance of an event handler function to each matching element.
While neither may be the case in a very specific ID example, there is no drawback to using it as a general approach. The only real downside to delegation at the root of the document is the risk of something canceling the event before it gets to the body which prevents it from bubbling to your handler.

Event delegation does not always make your code faster. In some cases, it's is advantageous and in some cases not.
You should use event delegation when you actually need event delegation and when you benefit from it. Otherwise, you should bind event handlers directly to the objects where the event happens as this will generally be more efficient.
Also, you should not bind all delegated events at the document level. This is exactly why .live() was deprecated because this is very inefficient when you have lots of events bound this way. For delegated event handling it is much more efficient to bind them to the closest parent that is not dynamic.

How to prevent lose event while replacing the area where the event registered

I have a click event created by plugin and after I load $.ajax and only replaced(update) the area where contain the click event, the event will lost.
<span ref='B'><span ref='A'></span></span>
//click event is on A, but I replaced the html inside of B to <span ref='A'></span>;
its update, so the replaced html are the same.
I read many related problems, I found the solution are
.live() // will not work
.delegate(), // work
.on(), // work
The solution is I should bind the event on B instead of A like B.on('click', A, function(){})....
However, my structure is very hard to change, I rather want to find a solution that can prevent lose events while replacing or alternative.
Please advice, thank you very much.
Solved by using detach()

Since event bindings exist within the context of DOM elements, when you start removing or replacing DOM elements, you need some mechanism to re-establish the event bindings.
A good approach is to use delegation via a parent element (as you have stated - B.on('click', A, function(){}).... ).
The other alternative is to always re-establish the bindings at the point at which the DOM elements in question are removed or replaced (so in your scenario, it sounds like this would have to be in the Ajax callback/completion handler) however this is generally a poorer approach and is much less elegant than the delegation method.

If you are concerned about applying the on event to a certain element on the page. Then I would recommend just binding the event to the document.
$(document).on('click', '#id-of-a', function(){
});
Read this blog post for more information concerning this.

I found a solution. This is possible with using .detach()! tested.

When using jQuery on(), why use (document) vs. the element itself?

I'd like a jQuery expert in their own words to explain why the $(document) identifier is recommended by others for jQuery's on() statement vs just using an element itself
Example 1: Why is using $(document) here better then Example #2?
$(document).on("click", ".areaCodeList a", function(){
// do stuff
});
Example 2: Why is using the element this way considering not good practice compared to Example 1?
$(".areaCodeList a").on("click", function(){
// do stuff
});

Both of those are valid.
The former works for dynamically added elements. You use document because you're delegating events on children of the document object, so events bubble up to the document level. It's also more convenient to select the closest parent you can (and the parent must exist on the page at load).
The latter still works, and is a preferred way to simply bind events to specific elements.
I personally don't recommend delegating through the document object, but rather the closest parent that exists on page load.
Here are the docs for on().

This is not true.
Those two lines do totally two different things.
The first one is a delegate event with the selector of ".areaCodeList a" while the second line is an event attached to the ".areaCodeList a" elements.
A delegate event will fire to every ".areaCodeList a" element although it was in the DOM when that line executed.
Anyway, attaching delegate events to the document isn't recommended at all. as written in the live docs:
Since all .live() events are attached at the document element, events take the longest and slowest possible path before they are handled
Please read the on docs:
Event handlers are bound only to the currently selected elements; they must exist on the page at the time your code makes the call to .on(). To ensure the elements are present and can be selected, perform event binding inside a document ready handler for elements that are in the HTML markup on the page. If new HTML is being injected into the page, select the elements and attach event handlers after the new HTML is placed into the page. Or, use delegated events to attach an event handler, as described next.
Delegated events have the advantage that they can process events from
descendant elements that are added to the document at a later time. By
picking an element that is guaranteed to be present at the time the
delegated event handler is attached, you can use delegated events to
avoid the need to frequently attach and remove event handlers. This
element could be the container element of a view in a
Model-View-Controller design, for example, or document if the event
handler wants to monitor all bubbling events in the document. The
document element is available in the head of the document before
loading any other HTML, so it is safe to attach events there without
waiting for the document to be ready.
...
...

I think you are confusing a few concepts. It is not recommended to bind to the document element, however there are times when you want to do so e.g when binding events to dynamically added elements.
All this may seem unclear, so here is the first example which uses the class selector directly and binds a click event, the element is inserted dynamically later after the event is bound. As you can see the event never gets fired because we selected an element that was not present in the DOM at the time the event was bound. This is equivalent to a .click
Now look at this second example. Here you see we are defining the root element as the document. Which means that the click event will bubble all the way up the DOM tree and then fire if the element that was clicked has a class dynamic. This is equivalent to .live
Now, if in example one, at the time of binding the event the element was present in the DOM, the code would work just fine, as you can see here.
That being said. Here's an except from the docs which clarifies the behavior above.
Event handlers are bound only to the currently selected elements; they
must exist on the page at the time your code makes the call to .on()
So, in conclusion. Use the document element when you are sure that there's no parent element for the element you are selecting that's guaranteed to be in the DOM at the time th event is bound. If there is a parent element that is present then use that instead of the document element. This way the event will not have to bubble all the way up the document, it needs to travel only a short distance.

There's nothing "recommended" about this. The first snippet sets up a "delegated" event, the latter is a "direct" one. The documentation for on() explains these in depth.
Delegated events are necessary when you need to listen to events for elements that don't exist yet - ones that will be created dynamically after, for example, an AJAX call. They can also sometimes be better performance-wise - you need less memory to attach a "real" event handler to the document object, than to 1000 buttons.
I'd say it's still preferrable to use direct event handlers when you can, or attach delegate events to an element as close to the real event sources as you can. Having all event handlers on the document object is probably terrible for performance - you have to match every event fired against all the selectors. It's also probably needed if you need to stop an event from bubbling - if all events are caught on the document, they've already bubbled as far as they'll go.

Actually the best solution in a case such as this is not using the $(document) neither the specific element like $("selector").
The best approach is using the container of the element and bind the element selector in the on function. By doing this you avoid unnecessary event bubbling to the document.
So the code should look like:
$("this_is_the_container").on('event','my_element_selector',function(){
// do some stuff here
})

$(*selector*).on(*event*, function(){})
will apply only for elements which is already load in page at the moment of script run. If in future, will appear new elements, the event handler will be not work.
$(document).on(*event*, *selector*, function(){}
will execute event handler even the elements with same selector will appear on page after script run.
So, if you have some elements, which can appear after in random time, use
$(document).on()
else use
$(*selector*).on();