Comment by CodeCompost

Htmx offers more flexibility than Alpine Ajax. Here's an example: htmx allows using relative selectors, which allow you to target elements relative to the triggering element in the DOM tree. This gives us a lot of power for swapping in pieces of UI without having to make up ids for lots of elements.

I have a blog post in the works for this feature, here's a small code sample I made to show the idea:

    <div class="card"> ╾──────────────╮
      <header class="card-header">    |
        <a                            |
          class="button is-link"      |
          title="Load links for #167" |
          role="button"               |
          aria-expanded="false"       |
          href="/app/notes/167/links" |
          hx-trigger="click once"     |
          hx-boost="true"             |
          hx-push-url="false"         │
          hx-target="closest .card" ╾─╯
    ╭───╼ hx-swap="beforeend show:none"
    |   ><b>±</b></a>
    |   <a
    |     class="card-header-title"
    |     href="/app/notes/167"
    |     hx-boost="true"
    |     hx-target="#note"
    |     hx-swap="outerHTML transition:true show:window:top"
    |   >#167 Velificatio</a>
    | </header>
    ╰╼
    </div>

I have tried to use exclusively each of the libraries to better understand their limit, overtime I got to the following observations:

- htmx is more straightforward (because a lot of the magic basically happening in the backend) and helps a lot to keep some sanity.

- Alpine shines when you need more composition or reactivity in the frontend. But it gets verbose quickly. When you feel you are reimplementing the web, it means you went too far.

For pagination, page structure, big tables, confirmation after post etc. I usually go with htmx. Modals, complex form composition (especially when you need to populate dropdowns from differents APIs), fancy animations, I prefer Alpine. (I probably could do that with htmx and wrapping it in a backend - but often more flexible in the frontend directly.)

To me, the main reason why I use these libraries, is what I write today will still be valid in 5 years without having to re-write the whole thing, and it matters since I have to maintain most of what I write.

Different libraries composing well together is the default assumption in most of software development. Only in Javascript have people given up on that and accepted that libraries don't work together unless they've been specifically designed, or at least given a compatibility layer, for the framework they're being used in.

> an entire ecosystem

Ecosystems have their downsides too. Just a small example, no htmx users were impacted by the React Flight Protocol vulnerabilities. Many htmx users have no-build setups: no npm, no package.json, nothing. We don't have to worry about the security vulnerability treadmill and packages and tools arbitrarily breaking and no longer building after some time passes. We just drive the entire webapp from the backend, and it just works.

Because that one library is vastly more complex

> instead of using one JavaScript library

One never uses just one JS lib :) The JS ecosystem always comes with lost of tools, and libs, and bells, and whistles.

I like Elm for this reason. Less choices. Zero runtime errors (I know it is possible in contrived examples, but I've seen and many teams have said the promise holds true after many years of using in production).

I needed Alpine mostly for small bits of interactivity in the page of an otherwise SSR app. Basically what I used jQuery for 20 years ago.

If you display derivations of server-side state in more than one place on the client, you're synchronizing it.

If you're not displaying derivations of server-side state in more than one place on the client, then you don't need HTMX.