In the browser DOM, what can element.addEventListener('click', fn) do that assigning element.onclick = fn cannot?

## Two ways to register the same thing The DOM offers two registration mechanisms for the same underlying dispatch machinery. The older one is the *event handler* — a property on the element named after the event with an `on` prefix: `onclick`, `oninput`, `onkeydown`. You assign a function to it. The newer one is `EventTarget.addEventListener(type, listener, options)`, available on every object that can receive events: elements, `document`, `window`, and other `EventTarget`s. Both end up calling your function with the event object, and inside a plain (non-arrow) function `this` is the element the handler is attached to in both cases. The differences are about *how many*, *with what settings*, and *how you take it back off*. ## The property is a single slot `onclick` is an ordinary IDL property. It holds exactly one function or `null`: ```js btn.onclick = () => console.log('save'); btn.onclick = () => console.log('analytics'); // the save handler is gone ``` Nothing warns you. The second assignment overwrote the first, and any code that later assigns `btn.onclick` wipes yours out too. That is why the property form is dangerous in shared code: two modules that both want to react to the same click cannot both use it. Clearing is symmetric and easy, though — `btn.onclick = null` unregisters the handler. ## addEventListener keeps a list `addEventListener` appends to an internal list of listeners on that target: ```js btn.addEventListener('click', save); btn.addEventListener('click', track); ``` Both run on a click, in the order they were added. Neither module needs to know the other exists, which is why every component library, framework internal, and browser extension uses this form. Removal is per-listener: `btn.removeEventListener('click', track)` leaves `save` attached. ## Only the API form takes options The third argument is where the platform keeps the interesting switches: ```js btn.addEventListener('click', onClick, { capture: false, // listen on the way down instead of the way up once: true, // remove me automatically after the first call passive: true, // I promise not to cancel the default action signal // an AbortSignal that unregisters me when aborted }); ``` The legacy positional form takes a boolean in that slot, which is the capture flag: `addEventListener('click', fn, true)`. There is no equivalent for `onclick` at all — a property handler is always a non-capturing, repeat-forever, non-passive listener. If you need any of those behaviours, the property form is out. ## They coexist, and ordering follows registration Setting `onclick` does not disable listeners, and adding listeners does not disable `onclick`. The property handler joins the same listener list at the moment the property is *first* set to a function, so ordering is simply the order of registration: ```js btn.onclick = () => console.log('A'); btn.addEventListener('click', () => console.log('B')); btn.click(); // A then B ``` If you then reassign `btn.onclick`, the replacement keeps the original slot's position rather than moving to the end. ## Inline on* attributes are a third thing Writing `<button onclick="save()">` in HTML sets the same property, but from a string of markup. That adds two problems beyond the single-slot limitation: the code is a global-scope string rather than a module-scoped function, and a strict Content-Security-Policy blocks it unless the policy explicitly allows inline script. Modern codebases keep behaviour in scripts and attach it with `addEventListener`. One genuine quirk of the handler form: because it has a return value, returning `false` from an `onclick` handler cancels the default action, which is where the old jQuery-era habit came from. An `addEventListener` callback's return value is ignored entirely — you call `event.preventDefault()`. ## What to actually use Use `addEventListener` by default. It is the only form that composes with other code, the only one that can be capturing, one-shot, or passive, and the only one that participates in `AbortSignal`-based teardown. Reach for `onclick` only when you are writing a tiny standalone script and you positively want "there is exactly one handler and assigning replaces it" — for example, wiring a single button in a demo page. And remember the removal asymmetry: a property handler is cleared with `= null`, never with `removeEventListener`.