If you were to incorporate a couple more functions, the impact would become evident:

var h = document.getElementById('a');
h.onclick = doThing_1;
h.onclick = doThing_2;

h.addEventListener('click', doThing_3);
h.addEventListener('click', doThing_4);

Functions 2, 3, and 4 function as expected, but 1 does not. The reason for this is that addEventListener does not replace existing event handlers, whereas onclick overrides any prior onclick = fn event handlers.

Another key distinction lies in the fact that onclick will consistently work, while addEventListener lacks compatibility with Internet Explorer versions pre-9. For IE <9, one can use the equivalent attachEvent (with slightly different syntax).

This answer will focus on explaining the three different methods used to define DOM event handlers.

Using element.addEventListener()

Example of code:

const element = document.querySelector('a');
element.addEventListener('click', event => event.preventDefault(), true);

<a href="//google.com">Try clicking this link.</a>

The element.addEventListener() method offers several advantages:

• Enables registration and removal of unlimited event handlers using element.removeEventListener().
• Includes a useCapture parameter for specifying handling events in either the capturing or bubbling phase. More information can be found here.
• Focuses on maintaining semantics, making it explicit when registering event handlers. This helps beginners understand that something is happening when a function call is made, as opposed to assigning an event to a DOM element's property, which may not be intuitive.
• Allows for a clear separation of document structure (HTML) and logic (JavaScript). This separation becomes crucial in larger projects for easier maintenance compared to intertwined structure and logic.
• Minimizes confusion with correct event names. It clarifies that event names like onclick or onload are incorrect, while correct event names such as click and load are passed to .addEventListener().
• Compatible with almost all browsers, including providing polyfills from MDN for support on older versions like IE <= 8.

Using element.onevent = function() {}

(e.g. onclick, onload)

Code example:

const element = document.querySelector('a');
element.onclick = event => event.preventDefault();

<a href="//google.com">Try clicking this link.</a>

Priorly known as the way to register event handlers in DOM 0, this method is no longer recommended due to the following reasons:

• Only allows registration of one event handler at a time, with removing the handler being less intuitive by resetting the assigned handler back to its initial state (null).
• Does not handle errors effectively. Assigning a string to window.onload without error feedback could lead to issues in identifying why the code isn't working properly.
• Lacks the capability to choose between event handling in capturing or bubbling phases.

Inline Event Handlers (onevent HTML attribute)

Code example:

<a href="//google.com" onclick="event.preventDefault();">Try clicking this link.</a>

Similar to element.onevent, inline event handlers are discouraged for the same reasons along with:

• Potential vulnerability to XSS attacks due to lack of Content-Security-Policy implementation to block inline scripts.
• Failure to maintain separation between document structure and logic.
• Increase in page length and loading times when generating multiple links with repetitive inline event handlers, impacting website performance.

Further Resources

• Documentation on EventTarget.addEventListener() (MDN)
• Documentation on

  EventTarget.removeEventListener()

  (MDN)
• Difference between onclick vs addEventListener
• dom-events tag wiki

Even though onclick is compatible with all browsers, older versions of Internet Explorer do not support addEventListener and use attachEvent instead.

An issue with using onclick is that it only allows for one event handler, whereas the alternative methods can handle multiple registered callbacks.

Key Points:

1. addEventListener allows for adding multiple events, while onclick does not support this functionality.
2. onclick can be directly inserted as an HTML attribute, but addEventListener is confined to <script> elements.
3. addEventListener has the capability to include a third argument that can halt event propagation.

While both methods serve the purpose of handling events, using addEventListener is recommended due to its versatility and additional capabilities compared to onclick. Avoid inline onclick attributes in HTML code as it confuses Javascript with HTML, leading to decreased code maintainability.

My understanding is that the DOM "load" event has very limited functionality. It seems to only work for certain elements like the window object, images, and <script> elements. This also applies to using direct assignments like .onload =, with no technical difference between the two methods. Perhaps using .onload = provides better cross-browser support.

It's worth noting that you cannot assign a load event to elements like <div> or <span>.

An element is limited to having only one event handler attached per event type, but can accommodate multiple event listeners.

Wondering how this plays out in practice?

Only the last assigned event handler will be executed:

const button = document.querySelector(".btn")
button.onclick = () => {
  console.log("Hello World");
};
button.onclick = () => {
  console.log("How are you?");
};
button.click() // "How are you?" 

All event listeners will be fired:

const button = document.querySelector(".btn")
button.addEventListener("click", event => {
  console.log("Hello World");
})
button.addEventListener("click", event => {
  console.log("How are you?");
})
button.click() 
// "Hello World"
// "How are you?"

Note for Internet Explorer: attachEvent is no longer supported. As of IE 11, use addEventListener: docs.

Something to consider is how modern desktop browsers distinguish between different button presses that qualify as "clicks" for event listeners like AddEventListener('click' and onclick.

• In Chrome 42 and IE11, both onclick and AddEventListener trigger "click" events on left and middle clicks.
• Firefox 38, however, only triggers onclick on left click while AddEventListener responds to left, middle, and right clicks.

The behavior of middle-click action can be very inconsistent when scroll cursors are in use:

• Firefox consistently generates middle-click events.
• Chrome may not fire middle-click events if opening or closing a scroll cursor.
• In IE, middle-click events occur when the scroll cursor closes but not when it opens.

Additionally, it's important to note that "click" events for keyboard-selectable HTML elements such as input can also be triggered by pressing space or enter when the element is focused.

When it comes to handling click events in JavaScript, there are two common approaches:

1. Using the `onclick` property:

element.onclick = function() { /* do stuff */ }

2. Using the `addEventListener()` method:

element.addEventListener('click', function(){ /* do stuff */ },false);

At first glance, these methods may seem interchangeable as they both listen for click events and execute a callback function. However, there are key differences between the two that make one preferable over the other depending on the situation.

The primary distinction lies in the fact that `onclick` is just a property, which means that if you assign multiple functions to it, only the last one will be executed, effectively overwriting previous assignments. On the other hand, with `addEventListener()`, we can attach multiple event handlers to an element without worrying about them being replaced.

To illustrate this difference, consider the following code snippet:

Try it out here: https://jsfiddle.net/fjets5z4/5/

While `onclick` may appear more concise and straightforward, it is generally discouraged nowadays due to its similarity to inline JavaScript, which is considered bad practice. Instead, using `addEventListener()` is recommended as the standard approach.

However, it's worth noting that `addEventListener()` is not supported in older browsers such as Internet Explorer version 9 and below. In such cases, sticking to `onclick` or utilizing libraries like jQuery that offer cross-browser compatibility could be viable alternatives.

var clickEvent = document.getElementByID("onclick-eg");
var EventListener = document.getElementByID("addEventListener-eg");

clickEvent.onclick = function(){
    window.alert("1 is not called")
}
clickEvent.onclick = function(){
    window.alert("1 is not called, 2 is called")
}

EventListener.addEventListener("click",function(){
    window.alert("1 is called")
})
EventListener.addEventListener("click",function(){
    window.alert("2 is also called")
})

Consider utilizing EventDelegation in your code! Personally, I find that using addEventListener is the preferred method while being mindful and deliberate in its implementation.

Key Points:

1. EventListeners can be resource-intensive (as they require memory allocation on the client side).
2. Events propagate inward and outward within the DOM tree, known as trickling-in and bubbling-out - familiarize yourself with these concepts if necessary.

Imagine a simple scenario: a button nested inside a div within the body... when you click the button, the event traverses from the window to document, down to the button, and then back out again.

In order for the browser to respond to a click event, it must track where each click was targeted, triggering any relevant event listeners along the way by sending the "click event signal" through the elements in the DOM structure.

By attaching EventListeners like so:

document.getElementById("exampleID").addEventListener("click", (event) => {doThis}, true/false);

Note that the true/false argument controls when the event is recognized - during trickling-in or bubbling-out.

Implementing event.stopPropagation() and event.preventDefault() within the function allows for more control over event propagation and default behaviors respectively.

Remember, the true/false flag in addEventListener also dictates when ".stopPropagation()" takes effect - either during trickling-in (TRUE) or bubbling-out (FALSE).

Using addEventListener over onClick in HTML offers advantages such as attaching multiple events to one element and better code maintenance practices.

• Event delegation ensures that multiple JavaScript functions can respond to a specific event without conflicting with each other, promoting clean separation between behavior and HTML for easier modification in the future.

One unique aspect of Javascript is its tendency to combine everything into objects, creating a sense of confusion for many users. This approach emphasizes merging all aspects into one cohesive JavaScript way.

For example, the usage of onclick as an HTML attribute contrasts with addEventListener, which functions as a method on the DOM object representing an HTML element.

Within JavaScript objects, a method serves as a property containing a function value that operates within the attached object (often utilizing 'this').

In this language, attributes of an HTML element represented by the DOM are directly mapped onto properties, contributing to the consolidation of elements without additional layers of indirection.

This merging process can be perplexing for individuals accustomed to more traditional object-oriented layouts, where namespaces maintain a clearer distinction between properties and methods.

domElement.addEventListener // Object(Method)
domElement.attributes.onload // Object(Property(Object(Property(String)))

While variations exist in implementation details, JavaScript streamlines these distinctions, combining domElement and attributes seamlessly.

As a general guideline, employing addEventListener is recommended for consistency and clarity, although alternative functionalities like onclick may also be utilized.

The dominance of this approach today stems from its simplicity, ease of use, and reliable performance.

By emphasizing direct application of event handling functionalities in JavaScript over relying solely on HTML attributes, users can maximize efficiency and flexibility within their code.

Additionally, developers have the option to create custom attributes in JS, expanding the level of customization and control within their projects.

$('[myclick]').each(function(i, v) {
     v.addEventListener('click', function() {
         eval(v.myclick); 
     });
});

Ultimately, understanding how JavaScript manages event handling through methods like addEventListener or onclick clarifies the significance of consolidating functionality within a single language framework.

Despite potential compatibility complexities, this modern approach showcases the adaptability and versatility of JavaScript programming, particularly in enhancing user accessibility and interactivity.

As per information from MDN, the distinction between the two is outlined below:

addEventListener:

The EventTarget.addEventListener() method involves adding a designated EventListener-compatible object to the collection of event listeners for the specified event type on the particular EventTarget it's invoked on. The event target could be an Element within a document, the Document itself, a Window, or any other object that supports events (such as XMLHttpRequest).

onclick:

The onclick property retrieves the click event handler code assigned to the current element. When utilizing the click event to execute an action, it is advisable to also include this same action under the keydown event, allowing non-mouse or touch screen users to perform the same action. The syntax element.onclick = functionRef; where functionRef signifies a function - often denoting a function previously defined elsewhere or a function expression. Refer to "JavaScript Guide:Functions" for further insights.

In addition, there exists a syntax variation in usage demonstrated by the following codes:

addEventListener:

// Function for altering the content of t2
function modifyText() {
  var t2 = document.getElementById("t2");
  if (t2.firstChild.nodeValue == "three") {
    t2.firstChild.nodeValue = "two";
  } else {
    t2.firstChild.nodeValue = "three";
  }
}

// attach event listener to table
var el = document.getElementById("outside");
el.addEventListener("click", modifyText, false);

onclick:

function initElement() {
    var p = document.getElementById("foo");
    // NOTE: showAlert(); or showAlert(param); will NOT work here.
    // It must reference a function name, not a function call.
    p.onclick = showAlert;
};

function showAlert(event) {
    alert("The onclick Event has been detected!");
}

Chris Baker made a great point in his answer, but I wanted to expand on it by mentioning the use of options parameter with addEventListener(). This parameter allows for more control over events. For instance, if you only want an event to be triggered once, you can include { once: true } when adding the event.

    function greet() {
    console.log("Hello");
    }   
    document.querySelector("button").addEventListener('click', greet, { once: true })

With this setup, "Hello" will only be printed once. Additionally, if you need to clean up your events, there is the removeEventListener() option. While addEventListener() has its advantages, it's important to consider compatibility with Internet Explorer. In some cases, this method may not work as expected. For more information on addEventListener, check out MDN's explanation.

If you're not too concerned about compatibility with different browsers, there's a method to rebind the 'this' reference within the function triggered by the event. By default, 'this' will point to the element that initiated the event when the function is called, which may not always be desirable. The challenge lies in being able to remove the same event listener simultaneously, as demonstrated in this sample: http://jsfiddle.net/roenbaeck/vBYu3/

/*
    Testing whether the returned function from bind can be referenced again,
    enabling it to be added and removed as an event listener.
*/
function MyImportantCalloutToYou(message, otherMessage) {
    // The following step is necessary since calling bind again does
    // not yield the same function; instead, we replace the original
    // function with the one bound to this instance.
    this.swap = this.swap.bind(this);
    this.element = document.createElement('div');
    this.element.addEventListener('click', this.swap, false);
    document.body.appendChild(this.element);
}
MyImportantCalloutToYou.prototype = {
    element: null,
    swap: function() {
        // This function can now be properly detached.
        this.element.removeEventListener('click', this.swap, false);           
    }
}

This code snippet functions well in Chrome, with potential compatibility shims for making "bind" work seamlessly across other browsers.

When it comes to Content Security Policy (CSP), using inline handlers can pose compatibility issues. This is why the use of `addEventListener` approach is considered more secure. Enabling inline handlers with `unsafe-inline` may seem like a quick fix, but it reintroduces the risks of JavaScript exploits that CSP aims to prevent.

In order to extend the listener, it is possible to prototype it if we have a reference to it and it is not an anonymous function. Alternatively, we can make the onclick call a function library that calls other functions.

For example:

elm.onclick = myFunctionList;
function myFunctionList(){
    myFunc1();
    myFunc2();
}

This approach allows us to modify the behavior of myFunctionList() without changing the onclick call. However, it does not provide control over bubbling/catching phases, so it is best avoided for newer browsers.

Using addEventListener allows for setting multiple event handlers, however, it is not compatible with Internet Explorer versions 8 and below.

Internet Explorer does provide attachEvent, but it functions differently compared to addEventListener.

When it comes to handling events in JavaScript, the onclick attribute essentially acts as a shortcut for adding an event listener that triggers a function when the element is clicked. This can be particularly handy for simple operations like those you might find on a calculator app. On the other hand, addEventListener offers more flexibility and control by allowing you to specify various types of events beyond just click, such as loading content or manipulating the DOM.

While it is possible to use multiple events inline or through onclick by separating them with semicolons, this approach can lead to potential issues down the line and make your code harder to maintain. It's generally recommended to keep your event handling separate from your HTML and call pre-defined functions from your script file instead.

The decision between using addEventListener or onclick depends on the complexity of the operation you are trying to perform. For more intricate tasks, addEventListener is typically preferred, while onclick is better suited for simpler actions. Some projects opt to have a global event listener that handles all clicks and determines the appropriate action based on the targeted element. While this approach may save some coding effort, it could introduce inefficiencies and increase the risk of errors if not implemented carefully.