Develop Reference

Click event for each element or one click event on the document for all?

Let's say I have bunch of click events. Also one/few of them is for document object.
Which one is better for performance? Click event for each element or :
document.addEventListener('click', (e)=>{
if(e.target == firstObject){ firstFunction(e) }
if(e.target == secondObject){ secondFunction(e) }
if(e.target == ThirdObject){ thirdFunction(e) }
})

Neither is "better." They each have their place in your toolkit.
A single delegated handler is more complex in that you have to do the kind of dispatch you're doing in your example (often using closest or matches), but has the advantage that if you're adding/removing elements you want to act on, you don't have to juggle event handlers.
Directly-assigned handlers are simpler (at least on elements that aren't added/removed), can prevent propagation, and let you keep your code more modular, more in keeping with the single responsibility principle.
Use the one that makes the most sense in a given context.

I think event listener for each element is better if possible, and makes sense in terms of code quality. There are some cases though where a document event listener will be needed ( for example to emulate a click outside behaviour)
That being said here are some of reasons that makes event listener for each element a better solution
event propagation is handled for you by the browser, if you decide to have only one event handler for the whole document, and u want to have event listeners for elements that are contained in each other, then you will need to handle propagation your self. That is to say you need to handle the order in which functions run yourself, and then you will have some either complex generic solution, or a specific imperative verbose code with a lot of if else statements.
Easier to read code, this is even more true for recent frameworks for web like react, angular, etc..., so for example assume you want to have a listener for clicks on the document, where that code should reside, in which file, and which component should own the code.
Removal of event listeners is handled for you by the browser apis, the browser gives you a way to remove event listeners. If you decide to go with a global event listener then you should handle removing event listeners yourself.
Your code will be hard to refactor and easier to break later, because you are coupling your document (or container ) event listener to your components internals. That is if you decide to change the structure of these components later, your document based event listener will probably break. This will depend a lot on how you identify the target of clicks, for example if you were identifying them by class names or other attributes, then these attributes might change later for reasons like styling.
and if you depend on ids for example you might eventually have unexpected results. because what happens for example if you added a listener for an element that has id, removed that element, and then later added another element with same id.
You miss on the development tooling provided for you by browsers, browsers can show you attached listeners for elements, with a document based event listener you wont be able to do that

It's better if you add one by one, because then you can remove event whenever it finish. Moreover you have more control about this event.

Is there any advantage to removing event listeners in jQuery/JavaScript?

I am using jQuery quite heavily in a ASP.NET WebForms application to handle anything client-side that isn't application-critical (eg. on the fly validation, animations, general fluff and pretty stuff).
Within this solution, I am using update panels, so the main page rarely gets refreshed. As such, event listeners can get bound on each asynchronous postback.
With this in mind (or in any other typical circumstances), is there any advantages to using .off to remove event listeners on elements that I know are not going to be active at that time?
Is the standard browser going to suffer much, if any, performance degradation if I leave the event listeners active, or will it only be noticeable at absolute extremes?
Should I just unbind (.off) when I bind (.on) at high-level elements such as body?
What is the best way to handle (if required) unused event listeners in a scenario where they are being bound and unbound multiple times over the life-cycle of a single web-page?
If you have any tests that show if browsers slow down with numerous event listeners, please let me know. Proven numbers would be perfect if anyone has them.

Leaving inactive event listeners will definitely show negative impact on performance. It is definitely a better practice to off unnecessary event listeners.
I would also suggest you to use scope while binding event listeners like
$(".demo").on("click.test", function(){ ... });
Here I have scoped the click event with test so that when I do
$(".demo").off("click.test");
any other demo class having an on click listener will not get switched off.

What is the most efficient way of registering event listeners in javascript

I'm trying to speed up my event registration. Can anyone tell me which will take up the least processing time -
$('#myElement').find('select.foo').on('click', 'option', handler1);
$('#myElement').find('select.bar').on('click', 'option', handler2);
or
$('#myElement').on('click', 'select.foo option', handler1);
$('#myElement').on('click', '.select.bar option', handler2);

I agree with the commenter who said "run some jsPerf tests". The first rule of optimizing is "don't prematurely optimize". Why are you optimizing? Are you having performance problems? If you are, are you sure you've isolated it to this code? That's what profiling will tell you. If it is this code, then you can figure out what method provides more performance.
I suspect that the first version will have higher performance because it will attach the event handlers to the element(s) that are closest to the event generation. The second version attaches the event handlers to elements higher in the DOM tree, so the events will have to propagate before they are caught, and then the event handler has to run a filter to see if the events come from matching elements.
Another way to look at this is that the first version identifies the elements that need listeners at page load time (doing the work then) and the second version identifies the elements that will respond to events as the events occur (spreading the work out and potentially creating more work -- possibly for good reason; see below).
Be very careful, though: often, the second approach is used when elements are inserted dynamically. It's the easiest way to solve the problem of event handlers not being attached to dynamically-added elements. So if you do have dynamically-added elements, then the second version might be your best option, performance considerations notwithstanding.

Attaching the listeners to the same object makes actually attaching the listeners take less time, but the process of catching and handling the events will be slower.
Attaching the listeners closer to the target takes more time, but handlers will fire quicker when the event occurs.
Thanks to this question for the answer - Should all jquery events be bound to $(document)?

Most efficient way to dynamically bind event handlers

Problem: I need to bind any number of event handlers to any number of elements (DOM nodes, window, document) at dynamically runtime and I need to be able to update event binding for dynamically created (or destroyed) nodes during the lifetime of my page. There are three options that I can see for tackling this problem:
I) Event delegation on window
II) Direct event binding on each node
III) Event delegation on common ancestors (which would be unknown until runtime and would potentially need to be recalculated when the DOM is altered)
What is the most efficient way of doing this?
A little context
I am working on a set of pages that need analytics tracking for user events (clicks, scrolling, etc.) and I want to be able to easily configure these event handlers across a bunch of pages without needing to write a script to handle the event binding for each instance. Moreover, because I may have the need to track new events in the future, or to track events on elements that are dynamically added to/removed from the page, I need to be able to account for changes in the DOM that occur during the lifetime of the page.
As an example of what I'm currently considering, I would like to create a function that accepts a config object that allows the programmer to specify default handlers for each event, and allow them to override them for specific elements:
Analytics.init({
// default handlers for each event type
defaultHandlers: {
"click": function(e) { ... },
"focus": function(e) { ... }
},
// elements to listen to
targetElements: {
// it should work with non-DOM nodes like 'window' and 'document'
window: {
// events for which the default handlers should be called
useDefaultHandlers: ['click'],
// custom handler
"scroll": function(e) { ... }
},
// it should work with CSS selectors
"#someId": {
useDefaultHandlers: ['click', 'focus'],
"blur": function(e) { ... }
}
}
});
Sources
SO: Should all jQuery events be bound to document?
SO: How to find the nearest common ancestors of two or more nodes
jQuery docs: $.fn.on()

I usually delegate events on the document.documentElement object because:
It represents the <html> element on the page, which holds everything which holds all the HTML tags the user can interact with.
It is available for use the moment JavaScript starts executing, negating the need for a window load or DOM ready event handler
You can still capture "scroll" events
As for the efficiency of event delegation, the more nodes the event must bubble up the longer it takes, however we're talking ~1 to 2 ms of time difference -- maybe. It's imperceptible to the user. It's usually the processing of a DOM event that introduces a performance penalty, not the bubbling of the event from one node to another.
I've found the following things negatively affect JavaScript performance in general:
The more nodes you have in the document tree, the more time consuming it is for the browser to manipulate it.
The greater the number of event handlers on the page the more JavaScript slows down, though you would need 100s of handlers to really see a difference.
Mainly, #1 has the biggest impact. I think trying to eek out a performance boost in event handling is a premature optimization in most cases. The only case I see for optimizing event handling code is when you have an event that fires multiple times per second (e.g. "scroll" and "mousemove" events). The added benefit of event delegation is that you don't have to clean up event handlers on DOM nodes that will become detached from the document tree, allowing the browser to garbage collect that memory.
(From the comments below) wvandell said:
The performance costs of event delegation have little to do with the actual 'bubbling' of events ... there is a performance hit incurred when delegating many selectors to a single parent.
This is true, however let's think about the perceived performance. Delegating many click events won't be noticeable to the user. If you delegate an event like scroll or mousemove, which can fire upwards of 50 times per second (leaving 20 ms to process the event) then the user can perceive a performance issue. This comes back to my argument against premature optimizations of event handler code.
Many click events can be delegated with no problem on a common ancestor, such as document.documentElement. Would I delegate a "mousemove" event there? Maybe. It depends on what else is going on and if that delegated "mousemove" event feels responsive enough.

Should I attach my .on('click') event to the document or element

Yesterday I was reading the jQuery docs for .on() where was stated:
Avoid excessive use of document or document.body for delegated events on large documents
But today, I was looking at this JSPERF and I notice a better performance when the click event is attached to the document.
So right now, I'm confused. The performance tests speak against the docs?

Your JSPerf here is testing the speed to attach events, not the effect that they have on cumulative page performance. This is the wrong thing to test!
Javascript events propagate up the DOM all the way to the document root. This means that if you have an on("click", ...) handler on document, then every click on every element in the document will end up running an event handler, so jQuery can test if its origin matches the delegate target, to see if it should be passed to that event handler.
Imagine that your page has 10 different delegated event handlers on document, all handling various clicks. Every time you click any element in the page, the event will bubble up to the document root, and all 10 of those handlers have to be tested to figure out which (if any) should be run.
In general, you want your delegated events to be as deep in the tree as possible while still enabling your functionality, since this limits the number of elements that may invoke this event, and you can handle the event earlier to prevent it from propagating up the DOM tree.

It depends.
You can attach handler to any element you want, of course, and in some cases you will have to attach it to document or body (if you, for example, want to target all the links on the page). But, if you are sure that certain elements will always appear only inside given element (which is already created) - then for performance sake, you can attach event handler to that common parent.

The point is excessive.
IMHO excessive delegates on any DOM is terrible