Hacker News new | ask | show | jobs
by afhammad 1258 days ago
Alpine.js is seeing an increase in utility as it pairs nicely with htmx[0], Phoenix LiveView[1] and the likes for lightweight interaction that doesn't require the server.

[0]: https://htmx.org

[1]: https://github.com/phoenixframework/phoenix_live_view

3 comments

Actually, HTMX has a fundamental flaw if it comes to history restoration: In some scenarios it takes snapshots of the DOM for history navigation, just before navigating away from a page. If the DOM was previously modified by other JS libraries like Alpine, jQuery or any other tool, these changes end up in the history snapshot, leading to unexpected results [1]. I've had a much smoother experience with Alpine + swup [2]. Disclaimer: I became a maintainer of swup this year.

[1] https://github.com/bigskysoftware/htmx/issues/1015

[2] https://github.com/swup/swup

To illustrate:

Say you have a collapsible menu (Burger etc.) which you just implement with a simple CSS based toggle. You open the menu and then navigate to a different page (via htmx). All good. But now your back button will break because it will send you to the previous page but with the menu open.

In this particular case it's _kind of fine_ depending on your navigation concept and design. It might even be a feature! But this behavior just proliferates little workarounds and caveats and can lead to surprising UI bugs, especially if you need some state management in-memory etc.

So htmx is great the less JS you use on top of it, except you are very aware of how it operates and how you interact properly with it's events. It's a very well designed and small library overall - with caveats.

Fair, I was going based on hearsay/docs. It looks like LiveView has been trying to accommodate the issue with some work arounds such as: https://github.com/phoenixframework/phoenix_live_view/issues...
HTMX has a complimentary framework like alpinejs called Hyperscript [0]. (On second thought not exactly like alpine..)

[0]: https://hyperscript.org/

I don't know as much about the underlying issue as the sibling, but I've also found that LiveView and AlpineJS interact in complex and unexpected ways in the case of components. The only sane way I found to integrate them was to make an Alpine-based component which is solely responsible for rendering itself, and then communicate updates back and forth with the LiveView process via custom events. That works but it's fairly heavyweight.
I would just make the jump to JS Commands if you're able.
I would like to be able to use Alpine in precisely the cases where the JS commands aren't enough. This case was one of those accursed custom form controls that designers love to come up with (a dropdown with checkboxes and a search filter).
Ha, right. I was in that same position. Unless you're working with a fixed, non-search, massive dataset, I found the performance is just fine doing it in pure Liveview over the socket, but I don't know your situation.
Yeah, indeed, doing it in pure LiveView is a realistic option, but it does degrade the user experience for e.g. someone on a crappy 3G mobile connection.
Right. Well, shit!