Comment by dlisboa
4 years ago
HTMX goes about it in the wrong way, in my opinion. HTML code should not carry state and logic. The moment you need something a bit more complicated than the common examples you’re in HTML-attribute soup trying to use a real programming language.
It’s better to just write that as a component in React or Svelte or whatever. It’s more testable, easier to understand, can carry state and logic just fine. It does mean you have to communicate in JSON for a small part of your app, but that is reserved to a few well known endpoints and components like a complex form.
The penalty is loading React or some other lib just for that, but if used in this way the extra dependency isn’t really a big deal as it’s not your whole app. Just use React as a library for components the browser doesn’t already provide.
And by components here I should really clarify as “affordances”. A “primary” button isn’t an affordance, the browser already gives you a button element and CSS classes (or HTML attribute) for that. It doesn’t give you a “multi page wizard with immediate validation” affordance, however, so that’s a good candidate for a component.
the original network model of the web was REST[1]
a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2]
htmx goes about it in the same way as the original web
perhaps that is wrong, but the web was pretty successful overall
[1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/
> perhaps that is wrong, but the web was pretty successful overall
Since HATEOAS is rarely implemented fully in practice, it would be simplistic to point to it as the reason the web is successful. The web allows an incredible variety of different architectures —- Some more closely aligned to HATEOAS and some less so. Perhaps this is the reason for the success of the web?
HATEOAS was and is implemented widely and effortlessly in hypermedia, since Fielding was describing the existing web architecture. It has failed fairly dramatically in JSON APIs, because JSON is not a native hypertext. Early API designers tried to shoehorn HATEOAS concepts into their APIs, which was somewhat plausible when APIs were XML, which, when squinted at, looked sort of like a hypermedia. Once we kicked over to JSON (and back to RPC as a network architecture) it became silly.
2 replies →
HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this.
When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation. That can't be the future.
yes, if you want to do things client side, hypermedia isn't going to be a great solution for you
htmx integrates with the existing HTML 5 validation API because, well, it's there, and that's what normal HTML does. I don't care much for the API, but that's the standard so we follow it. You can, of course, do client side validation however you'd like and integrate it with htmx using events, since events are the proper glue to tie things together in the DOM. I built a scripting language to help with this, and other stuff as well, called hyperscript: https://hyperscript.org
the "htmx" way for validation is the HTML/web 1.0/HATEOAS way: submit the form to the client side, validate and re-render. With htmx that can be inline, rather than a big clunky refresh-the-page action, which is why I say htmx extends and completes HTML as a hypermedia.
So long as you aren't willing to think about things in hypermedia terms, and htmx as an extension/completion of HTML as a hypermedia, you are going to miss the point. That's not to say that the hypermedia approach is always right, it isn't, but with htmx a lot more of the web application problem space is addressable with that approach.
And, as an aside, HATEOAS isn't great, outside the context of a hypermedia.
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
It is, rather, a fairly pointless category error, driven mainly by cargo-cult mentality from the early JSON API era.