For several years, I've been mostly against event handling code in HTML attributes. And for the longest part, it really was a terrible idea.

With modules alone, it becomes really hard for onclick handlers to call code. Not without polluting the global namespace, at least.

But now I'm starting to warm up to them again: thanks to custom elements, code can live in modules and still be triggered via DOM attributes, by using custom elements as the interface:

<custom-element>
   <button onclick="this.closest('custom-element').doThings()">
      Click Me!
   </button>
</custom-element>

The actual logic, the doThings method, still lives in a separate model decoupled from the goings on of the DOM, and yet the button can cause it to run without needing any additional JavaScript to connect the two.

The DOM is what connects the elements, which is exactly how it should be.

Sadly, the web is so close yet still so far from an even better solution:

<button commandfor="element-id" command="--do-things">
   Click Me!
</button>

This would be an even nicer solution by eliminating the closest() boilerplate and replacing the method call with an event. Sadly, it only works with IDs, regardless of DOM proximity.

If I could make a wish, I'd change how commandfor works to just take a CSS selector and treat it as an argument to the closest() method unless it starts with a #, but that's not the world we live in.

In this world, onclick is a very good albeit slightly more verbose replacement.

Edit to add: I should probably mention that for more complex situations, I am also quite fond of <button x-event="custom-element:do-things">Click Me!</button> with a click listener on the document root that intercepts click events on buttons with the x-event attribute and dispatches a custom event of that name instead.

It's a convenient way to simplify HTML while keeping the logic mostly decoupled from the structure of the DOM.