A few features which look minor but the author got totally right, which IMHO would allow this solution to scale very well with more complex applications.

1) X-Alpine-Target

``` <form method="post" action="/comments" x-target="comments comments_count" ```

generates an ajax request with this header by default:

``` X-Alpine-Target: comments comments_count ```

This is very very cool! In most usecases, one the serverside I can return a full html document and alpine-ajax will only look for #comments and #comments_count in the response. BUT, if I want the serverside to be faster (ie: do less), then the client is able to tell the server which parts of the html it wants via the `X-Alpine-Target` header -- instead of the server having to know which parts need updating via the url alone. It's like graphql for the htmx/hotwire architecture.

2) `ajax:missing`. If the client expects dom ids to be in the response and they aren't there, you can create a sentry error to expose the broken "contract" between the initial page's request and the action's response.

3) x-merge="append"

In hotwire, the html markup is dumb and the turbo-stream response is smart (`turbo-stream action="append"`). But in alpine-ajax, the response is dumb and the html markup is smart (`x-merge="append">`). This difference is subtle, but it allows for the serverside responses (for actions) be more general purpose/discrete components, while the ux which might change from page-to-page or section-to-section is decoupled to that page's/section's container html.

4) x-sync

"Elements with the x-sync attribute are updated whenever the server sends a matching element, even if the element isn't targeted with x-target."

Wow - amazing developer ux for cross cutting concerns like notifications, flash messages, etc. So practical.

5) Creating demos with an alpine-ajax mock server.... wow, an out of the box way to make standalone component test pages.

My first reaction was “why do I need an htmx-like version written in alpine?” when I could just use htmx. BUT… if you assume that you will need something more low level to complement htmx (“htmx + alpine” OR “htmx + hyperscipt”) and if you decide hyperscript is not for you, then it does make sense to a stack where the higher level is built upon the lower level: alpine-ajax + alpine.

Looks very interesting!

Also loved the comparisons, especially with rails/turbo and the downsides of custom elements wrt tables.

Wait a second, this makes way more sense than it should.

I’ll have to play around with this but glad to have another great library with this mindset.

I always am unsure of whether to go with unpoly, livewire and htmx lol. Maybe this will push towards htmx

All of these related projects remind of Dojo Didgets from the mid 2000s. Not that that's a bad thing, I found that tool kit very productive!

Anyone else remember Dojo fondly? Am I way off base here?

That looks interesting. It resembles Unpoly approach to me.

Quick question about redirect with `nofollow`. Does it do a full page reload or just refresh a page like Turbo (swaps body and merges head)?

Looks very cool!

I also love the 50s styling and theme. Awesome job!

I use Livewire v3 (also fully Alpine based now) in my latest project and it has truly transformed my approach to web apps. It’s truly amazing.

Can it do something similar to hx-trigger="load"?

looks sweet! wanna try out building something using HTMX. i'm curious about its limitations in terms of project size/complexity

Nice! But how to deal with i18n?

No JSON needed? I like JSON

It would be JQuery...

Try uajax on GitHub