You can reimplement htmx functionality with Alpine, but htmx is a lot better than `@click="fetch('/partial').then(res => res.text()).then(frag => $el.innerHTML = frag)"` all over the place (with a slight variation in that one component that you miss because of the noise).
Don't use _hyperscript just to be "'`consistent`'", use it because you want to. Being agnostic and playing well with other tools is a big thing for htmx. _hyperscript is lots of fun and lets you write very readable code, but you also need to stomach a 26mb bundle just to toggle some classes :/
(if anyone reading this can help us make it smaller, LMK)
ackshully, 21.2 kB:
https://bundlephobia.com/package/[email protected]
Which compares pretty well w/ alpine, which comes in at 21.7kB with its dependency:
https://bundlephobia.com/package/[email protected] - 17kB https://bundlephobia.com/package/@vue/[email protected] - 4.7kB
:)
AlpineJS (and hyperscript) are better for purely front end needs.
htmx and Alpine pair well together, as does htmx/jQuery, htmx/VanillaJS or, if you are brave, htmx/hyperscript
I honestly still don't see the point of htmx, to me alpine.js + axios can cover all the front needs, assuming backend returns json instead of html.
htmx is useful for django etc when it's returning html though, but new frameworks are more likely to return json instead.
alpine increases client side interactivity, it can also do ajax to talk with server, why do I still need htmx then?
On the other hand if I use htmx I will probably use its hyperscript for interactivity on the client side, to be 'consistent'.
Note both projects are trying to make frontend simpler, mixing them seems not to help that goal to me.