Behavior belongs in the HTML

This seems a bit discombobulated. You shouldn&#x27;t be using a `&lt;button&gt;` at all but a `&lt;input type=submit ..` for most of the examples. The search example shouldn&#x27;t be changing it&#x27;s name (query-&gt;q) for new practitioners following along, and should be using `&lt;input type=search`.<p>In the `too-short-message` example where is the `not-long-enough` message defined?<p>Then we run off into microformats, they&#x27;re great, but out of scope (and never tied back).<p>The button extension using custom attributes should be getting attribute `message` (not `type`).. but that&#x27;s probably a typo. A potentially more reasonable attribute would be `title` since in many desktop browsers you&#x27;ll get a hover tooltip (which might be beneficial, although for the contrived example perhaps not.. on the other hand, why would you want a multitude of alert buttons?)<p>And then there&#x27;s zero consideration for Content-Security-Policy[0], one of the current reasons you&#x27;d avoid inline JS (`unsafe-inline`) in favour of script tags that can have `nonce-*` or `sha256-*` signed content.<p>[0]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CSP" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;CSP</a>

It’s really amazing watching trends in web UX reverse in realtime. Can’t wait to log in and find one day that flexbox&#x2F;grid are bad and we’ve reinvented table and frame layouts.<p>There are loads of web apps that have rich interactivity where mixing presentation with supporting logic creates a real mess. Say you’ve got a grid with a million (gasp!) rows. You’re really gonna emit all that unnecessary inline JS behavior over the wire?! Why on Earth?? What if you need context binding? You could just have a jQuery .on handler registered once at the parent and filtered to all buttons, which pulls the id of the record from a data-attribute on the target element, finishing the same work in a couple of lines of code in one easy to maintain spot. Yes, adding addEventListener code all over your app would be repetitive and wasteful, but that (amongst browser incompatibilities) is why jQuery was invented, but you can hand roll your own utility or use HTMX or a million concise tools to do this. Including a right-sized dependency isn’t going to kill you. Sure, if you’ve got a stupidly simple HTML page with a couple elements with a handler or two, fine, go ahead, knock yourself out. I disagree with this one-size-fits-all assertion. We did a lot of this before and it sucked.

I did not see mention of event delegation in the article.<p>Registering thousands of event handlers on one screen can have performance impact, and is generally why registering them on individual elements becomes a problem for an interactive page. Registering on a parent element can provide the same interactivity with only a single handler thanks to event bubbling.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;JavaScript&#x2F;Building_blocks&#x2F;Events#event_delegation" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;JavaScript&#x2F;Bu...</a>

There is definitely something to be said for the locality of the definition with the element. Tailwind has shown that many (myself included) see defining your styles directly in your elements as preferable to doing it externally.<p>JSX and templating in other frameworks gives you that desirable locality, which I think is why it can feel so painful to go back to vanilla js.<p>I still default to plain ol&#x27; vanilla JS on a lot of things, but having to add definitions to elements after first grabbing them with selectors is annoying, particular for singular elements.

This is an enjoyable read, and while many of the specifics are arguable, the core essence, to me, is encapsulated by a famous Ralph Waldo Emerson quote: “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.&quot;<p>Too much of this industry is dogmatic pursuit of absolutes. The submission notes the documentation declaring that one should <i>never</i> use event attributes, arguing an illusory separation. Similar sorts of absolutism can be found in almost every tactic and approach. Too often many seek to simplify the choices we need to constantly make by making some of the options verboten. Its why everything old is new again and we seem to constantly have camps reverting to forbidden approaches and now decrying their replacements as the bad option.

I personally like the separation of concerns that HTML&#x2F;CSS&#x2F;JS evangelizes and I feel like it lines up well with how the old school MVC frameworks want you to think about things.<p>I think a good middle ground here is that HTML web components article that was shared here a few weeks ago: <a href="https:&#x2F;&#x2F;gomakethings.com&#x2F;html-web-components&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;gomakethings.com&#x2F;html-web-components&#x2F;</a><p>I like this because it&#x27;s still fairly low-code but you get cool stuff out of the box like attributeChangedCallback. You don&#x27;t have to mess with build tools, which is what I like the most about this strategy. I can just drop these components into my Rails views like any other element, and their custom functionality gets mounted up as soon as they get folded into the DOM. No more document.querySelectorAll(&quot;.foo-bar&quot;).forEach(foo =&gt; bar()). Much cleaner, and the intent is more clear too. With &lt;foo-bar&gt;, it&#x27;s much more obvious that the element has scripting attached to it than &lt;div class=”foo-bar&quot;&gt;.

This doesn&#x27;t really resonate with me. It feels like the author&#x27;s main point boils down to the fact that the only currently (officially) supported way to have custom attributes in HTML is with data-* attributes. I guess that&#x27;s a fine opinion to have, but their example in the conclusion really doesn&#x27;t look very different to me than if the same code was written with `data-alert data-message=&quot;...&quot;`. One big reason I like using javascript for behavior is that it&#x27;s an actual programming language, so I get all the benefits of things like modules and variables. Its reasonable to argue that more custom attributes should be used vs. lots of verbose JS, but that&#x27;s what data attributes are, I don&#x27;t see how 5 characters is hurting us that badly. The author criticizes data attributes for being implicitly focused on data rather than behavior, but I&#x27;d argue the author&#x27;s own final example is also defining data rather than behavior: adding an &quot;alert&quot; attribute is a piece of data that indicates the button will show an alert on click (a <i>behavior</i> that the author adds with javascript) and the &quot;message&quot; attribute indicates the message that will be shown (inherently a piece of data IMO). I must have missed something because I found this article entirely unconvincing.

I still find that HTMX et al. have weird tooling. I get so much value out of a debugger, especially with event handling, and getting a weird mystery Alpine&#x2F;HTMX&#x2F;Hotwire call stack back is kind of weird.<p>Still though, I like it in theory. JSX still feels closer to an “ideal” syntax to me, even if there’s a lot to complain about there as well.

If the choice is between using HTML in JS (e.g. JSX) vs using JS in HTML (essentially, that&#x27;s what HTMX is), my choice is unequivocally the former. Ignoring some very basic use cases, UI apps are all about state and interactivity. HTMX can somewhat handle interactivity (very awkwardly in my opinion), it offers nothing over React in terms of state management.

Apparently we&#x27;re going through a stage right now when the loud voices have decided everything belongs in the HTML. Tailwind and HTMX are both frameworks trying to stuff everything in the HTML, which works great in simple demos and becomes hilarious in any more complicated real-world project.<p>The naive and inexperienced will follow those trends, and will generate countless &quot;why I stopped using...&quot; and &quot;... considered harmful&quot; blog posts 1-2 years from now, when frustrated, they&#x27;ll flip on their God and declare them Satan.<p>Those who have been through these cycles before will smile, shake their head and know there&#x27;s nothing that can be said to dissuade them, until they learn painfully from their own experience. And the wheel keeps turning.<p>For the record, behavior doesn&#x27;t &quot;belong&quot; anywhere. The optimal solution varies based on the type of project and content. Considering the historical baggage of HTML and how specific it is to the browser, while many apps are multiplatform these days, I could easily argue HTML is the worst place to put your behavior.

The entire second half of the article acts as if custom elements aren&#x27;t already supported in HTML:<p><a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;custom-elements.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;custom-elements.html</a><p>You can go ahead and create &lt;whatever&gt; &lt;custom-elements&gt; with whatever attributes you want and it&#x27;ll work.

context: the author is a core maintainer for HTMX

The author&#x27;s argument about SoC is not convincing. He: &quot;is, in my polite opinion, completely wrong&quot;. The graybeards are right on this one.<p>For those of us who remember working with &quot;DHTML&quot; before libraries like jQuery proliferated, and then jQuery became ubiquitous for a few years - many of us recall the messes that the simplistic technique of using intrinsic events gave us.<p>When intrinsic events were introduced (e.g. the onclick attribute), they were meant to wire up some simple DOM behavior to Java Applets. Then somebody convinced the W3C people that it was a neat idea, and it needed to be in the HTML 4 spec.

I die inside a little every time I read a sweeping assertion followed by some contrived examples. Does anyone find this kind of thing convincing? You can make anything sound plausible if you pick the right cute little snippets.

I find it interstring the author goes from saying &quot;This is, in my polite opinion, completely wrong.&quot; with regard to this from MDN: &quot;You should never use the HTML event handler attributes — those are outdated, and using them is bad practice.&quot; to finally presenting a solution that doesn&#x27;t use HTML event handler attributes. I was expecting them to show me the use of these attributes in their solution, but they don&#x27;t.

I&#x27;m more of a fan of this than the separation; I&#x27;d rather have a generic library provide the data-* options for things and keep the semantics more local.

Focusing in on the contrived example re: native &lt;form&gt; behavior and nothing else, if given the choice I would rather remove the default behavior &#x2F; &quot;action&quot; than adding more functionality to html.<p>I love html, and I love writing nice clean markup that clearly defines a document, so that you can look at the html without css and js and know what information it is presenting to you. I really don&#x27;t want it to do anything else.

I think the author is confused here. HTML belongs to the internet of the library and has been feature complete for some time now.<p>For the internet of the shopping mall you would use HTMX or some such and that should be enhanced or pimped to the max by all means. Inline, webassembled and reactified riding the tailwind. Go for it, knock yourselves out and make a killing. How about bigger screens for all the popups?<p><i>need more buttons</i>

I don&#x27;t want to disagree because you put a lot of thoughts in it obviously, but HTML also stands for? :o)<p>So although you&#x27;re right that it does a bit more, it wasn&#x27;t and probably shouldn&#x27;t be used for other than document presentation over the web.<p>That&#x27;s the reason javascript got introduced: the custom designed and dynamic parts.

This article seems well meaning, but it contains factually incorrect information.<p>Its is also redescribing well defined concepts subjectively but presenting them objectively, and this is unfortunately a constraint that eliminates the value of the article.<p>Ty.

It sounds like this author wanted to recommend web-components but doesn&#x27;t know they exist. This is exactly what web-comps solve, writing custom HTML elements that are interacted with like native ones, in native HTML.

I&#x27;m learning to use htmx these days, I just wish htmx can have a little more local interactivity builtin instead of using hyperscript, which is hard to memorize its syntax.

I do love how deeply &amp; carefully Alex thinks about this stuff.

Zenarmor WAF classified this site as a &quot;dead site&quot; and blocked it.<p>Just wanted to let you know OP.

Time is a flat circle.

People seem to forget that HTML is a markup language used to describe the content of a document. Once one remembers that, and thinks about that, everything about HTML becomes very clear, easy and manageable.