Hacker News new | ask | show | jobs
by pabe 1046 days ago
I wondered how Unicorn compared to htmx. They're giving an answer on their website:

htmx and alpine.js are great libraries to provide interactivity to your HTML. Both of those libraries are generalized front-end framework that you could use with any server-side framework (or just regular HTML). They are both well-supported, battle-tested, and answers to how they work are probably Google-able (or on Stackoverflow).

Unicorn isn’t in the same league as either htmx or alpine.js. But, the benefit of Unicorn is that it is tightly integrated with Django and it should “feel” like an extension of the core Django experience. For example:

* redirecting from an action uses the Django redirect shortcut

* validation uses Django forms

* Django Models are tightly integrated

* Django messages “just work” the way you would expect them to

* you won’t have to create extra URLs/views for AJAX calls to send back HTML because Unicorn handles all of that for you

2 comments

Doesn't HTMX work via HATEOAS so would require a full RESTful backend?
You can just respond back anything and it'll work. You can just respond a flat non-hypermedia JSON and have some JavaScript listen to the event and process it with whatever semantics you want (although it'd be weird for you to do that, but I just tried it and yeah it works).

I still don't understand what they mean when they say "HTMX is HATEOAS": it's not parsing the response to decide things based on relations, it's not following any links, you can still have out-of-band info if you want...it's just substituting a string given by the server on the DOM.

A JSON API can be as hypermedia as HTML (I remember HAL-FORMS and Collection+JSON). A web app that consumes such an API is doing "HATEOAS" even if it's using React.

I really like the HTMX project (that and Unpoly are a godsend) but sometimes it sounds more grandiose than it is: just the regular web doing what it always did, except you program the interactive fetching/swapping of pages/fragments in HTML instead of JS, i.e. AJAX with HTML attributes.

Gotcha. I may have to give HTMX a try again. Though, I worked on a HAL-based, full RESTful service back in 2016 and I'm not sure how eager I am to go back.

REST was ok for the read-side of things, but for writing I find RPC/commands to be better than PUT/PATCH. Combine that with the lack of framework for HATEOAS made full REST APIs cumbersome at the time, though things may be different now.

I wouldn’t consider htmx “battle tested”.
Isn't htmx intercooler.js without jquery, which is (intercooler) a 10 years old library been used extensively in a lot of sites?
funny, the reason i say its not battle tested is because of an issue i discovered in the extension system that was mentioned in that post.
Aside:

htmx is a very small and very predictable library. The underlying pattern is well established among many libraries and probably countless similar implementations.

I have implemented something like htmx several times before htmx came out, and I assume many others have too. I just didn't take the time to extract a clean, generalized and comprehensive library.

I personally found a glaring performance issue in the library related to plugins and created a github issue for it back in December (I don't think it's been fixed to date). I was confused because it was pretty obvious. "Battle tested" things, by definition, have been through battles and don't have as many easy pickings on optimizations.