let's say that you have an upvote button

   <button hx-post="/upvote"
           hx-trigger="click"
           hx-target="#notification-bar"
           hx-swap="outerHTML"
       >
     Upvote
   </button>

Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.

That's because this example is an anti-pattern, the swap should be local [1], the button changes itself (to an orange arrow, to disable itself, etc) and the notification tag (#notification-bar) should be responsible of its own behavior.

An idea could be that the notification bar is polling a notification endpoint every Xsec or on a specific event [2], or if you want to be fancy with WebSockets [3]

[1] They actually talk about this: https://htmx.org/essays/locality-of-behaviour/

[2] for example afterRequest or afterSwap : https://htmx.org/events/#htmx:afterRequest

[3] https://htmx.org/extensions/web-sockets/

HTML ids are globally unique so the answer is wherever `id="notification-bar"` lives.

Isn't this comparable to any other situation where you reference something outside a project, even in C with libraries?

(I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.)

If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply grep '#notification-bar' and see where it lives in the project...

I think the goto comparison is somewhat related, because it's about reasoning about control flow (or rather, how it makes it unreasonable) - but isn't this example pretty easy to reason about when you consider you're one search away from finding the notification-bar in the project? You're still creating a tree of components and interactions, and in order for that to happen, you must be able to reference them with confidence in some way.

I still prefer the React way (tree structured components) regardless, but HTMX does seem interesting from a DevX point of view. I think it'll be forgotten about in about 5 years.

if you decided to write C by building a lot of tiny global functions with no local state that called other globals functions, then it would greatly resemble programming with GOTO.

> a lot of tiny global functions with no local state that called other globals functions

Isn't that Haskell?

What’s the difference to writing vanilla JS to do the same thing?

no differerence at all. jQuery functions like

  $('.foo').on('click', () => $.ajax(... $('.bar').html(result) ))

become unmanageable just as quickly.

So your complaint is not about HTMX, but about using any kind of JS without using a framework like React.

You don't need a framework like React but you should try to implement modules that are explicit about their dependencies and use local state as much as possible.

For example the upvote could be implemented like this:

  function renderUpvote(container, showNotification) {
    $("<button>").appendTo(container).on("click", () => $.ajax( ...
      result => showNotification( result ))
  }

Now the notification action is passed in from a parent component. It's easy to trace where it comes from. You can also declare local variables in this function and have confidence that they will only be manipulated by callbacks within the module. This is how I wrote frontend code before React came out.

That’s great for building JS apps, not so much for progressive enhancement of HTML.

I’d really like some explanation about what I’m misunderstanding, downvoting without explaining anything doesn’t help anyone.