Replies: 1 comment
-
I'm not familiar with the pure definition of it, just wanted to reference to the HATEOS essay on the website in case you had missed it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I don't intend to criticize htmx by this, just wondering if HATEOAS indeed is a good description, because it confuses me a bit. Am I supposed to aim for HATEOAS with htmx?
What I associate with HATEOAS, is the way the current dom reflects the state of the client app. I struggle to see how this is maintained with htmx. With HATEOAS the relevant state will not be on the server at all, but with htmx, you typically update server state, which then uses this server state to render your responses. With HATEOAS, there is no such state, but the current dom has the state implicitly in it, and this is enough. The simple case, is simply navigating between links, and the client state is replaced with a new one, and the possible next states are captured in the links. With forms, the user manipulates the dom state, sends a new request based on that, and gets a new state, with possibly a new form with hidden state in it. The server knows nothing of each browser session for the purposes of tracking it's state, but each request contains the entire necessary information to compute the next complete state representation for the client.
This is a very simple and ingenious mechanism, that underlies how the web works fundamentally, and it is the foundation even of a SPA app ability to be bootstrapped on any browser by linking to it, in that case the "state" from the browsers perspective, is simply the entirety of that application running, the rest is opaque from the view of web fundamentals, and not part of the web semantics directly.
With HTMX it seems you send a lot of tiny requests that update tiny parts of your state, but the "engine" of the state resides in arbitrary server state, not in the hypermedia. Thus typically it's not HATEOAS at all, as I understand it. This is not necessarily bad, but it is confusing to use the term HATEOAS, when that is not what it typically becomes. HATEOAS would allow e.g. the back button to function naturally in all cases without thinking about it, as all the browser would do is load the previous dom. This does not work with typical HTMX apps as far as I understand. Again, that might be fine, but the HATEOAS aspect is not there as far as I understand it.
But I might simply be mistaken about what HATEOAS actually is, though I have tried reading Fieldings dissertation several times, and thought I understood it.
Beta Was this translation helpful? Give feedback.
All reactions