Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Alpine Ajax – If Htmx and Alpine.js Had a Baby

alpine-ajax.js.org

Post reply on HN
Print view View original

1–10 of 26 posts

Re: Show HN: Alpine Ajax – If Htmx and Alpine.js Had a Baby

#7

Post by tomhallett »

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.

Re: Show HN: Alpine Ajax – If Htmx and Alpine.js Had a Baby

#9

Post by imacrayon »

tomhallett wrote: post #7

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…

Yes! You’ve reminded me that there’s some subtle gotchas when using HTMX server-side that are probably worth documenting too. For one, HTMX starts with the assumption that you’re returning HTML fragments, but not all templating languages have good support for decomposing layouts into fragments. You can work around this using hx-select but Alpine AJAX works kind of like hx-select by default. Also, there’s some response header juggling you have to do when submitting forms that have a validation step before redirecting: https://github.com/bigskysoftware/htmx/issues/369

I’ve tried to iron out any footguns or server requirements I’ve bumped into while using HTMX & Hotwire in my projects.

Re: Show HN: Alpine Ajax – If Htmx and Alpine.js Had a Baby

#10

Post by tomhallett »

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

``` 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.

Post reply on HN