To the unfamilar, HTMX is one of the currently-most-popular libraries in a long line of libraries attempting to move logic that traditionally is in JavaScript into HTML, usually via custom attributes or data-* attributes with a custom language inside.
I have a lot of complaints about libraries that attempt this, chief among them being "how do I set a breakpoint?" I started writing an annoying complaint-post about it but realized I should do at least a little due diligence before complaining. So I went to their essays page to give some of their theory a proper read.
The Locality of Behavior essay struck me. I like the quote it starts with, but the principle itself seems reductive to me as it focuses too specifically on having to look at more than one file as the primary axis of "locality". But then they spit hot fire:
However, it is important to make the distinction between inlining the implementation of some behaviour and inlining the invocation (or declaration) of some behaviour.
This is really great! This is my major problem with aspect-oriented programming—it has no indication that something somewhere is affecting the behavior of the code you're looking at. Being explicit about these links is critical to writing code maintainable by people who aren't you1.
The major complaint of "JavaScript event handlers add behavior that is difficult to see when looking at the HTML" is rooted in the idea that you're looking at the HTML as the root code of the page that JavaScript and CSS modify from the outside. But there is a place you can look that shows these event handlers and outside styles inline with the HTML: the browser devtools!
This, I think, is my core contention with HTMX and similar libraries. Moving things like behavior hooks and logic into HTML only seems like it reduces complexity because it presumes that the HTML is the source of truth for what your app is doing. But if you look at what the browser actually treats as the source of truth, the DOM, you'll find that logic is already accessible directly from the browser devtools. This is why integrating the devtools into your workflow (e.g. making CSS/JavaScript changes directly in the devtools and then copying them back to your source code) is such a useful technique vs tweaking source code and refreshing the page—working directly on the DOM has a much tighter feedback loop given that it is the source of truth for the page.
-
And you in 6 months from now is a different person, too.
