
A few thoughts on onclick and how my opinion on it has changed.
title: onclick is great, actually
published: true
description: A few thoughts on onclick and how my opinion on it has changed.
tags: javascript, html
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.
aiMost of us have seen a coding agent fail to complete a task we know it can do. We just don't...
googlecloudWhen building Generative AI applications, developers often encounter a massive bottleneck: sequential...
discussI’ve been thinking about sharing some electronic circuit posts on Dev.to — small circuits, DIY...
agentsWhat nobody tells you about exporting your multi-agent prototype to a local workspace. Every...
agenticarchitectAutonomous agents are genuinely good at answering messy business questions. Give one an LLM and a set...
aiPR volume went up, ticket quality didn't, and the gap got filled with LLMs on both sides of the review: bots reviewing, bots replying, bots occasionally arguing with bots about priorities that only existed in a teammate's head. Our CEO named the actual problem, and it's bigger than code review.