4 ms·

https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/

lakomen 4y ago
I hate HATEOAS with a passion. Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot. If htmx has anything to do with HATEOAS it's going to be ignored out of principle.
- _heimdall 4y ago
  Mind sharing why you have such strong opinions on HATEOAS? Is you problem that there aren't many implementations of it today or concerns with the architecture itself?
- recursivedoubts 3y ago
  That's because you are using in a JSON API context, where it doesn't make any sense. HATEOAS (or, as Fielding prefers to call it, the hypermedia constraint) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up. I try to explain why this is here: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... and I try to explain what HATEOAS really is here: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ and I try to explain why HATEOAS has been, by and large, a failure outside of true hypermedia clients presenting directly to humans here: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
ukuina 4y ago
Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible? In a serverless read-only app, all business logic and state is maintained on the browser.
- decross 3y ago
  You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service https://github.com/richardanaya/wasm-service
  - ukuina 3y ago
    This is cool! A possible extension to HTMX would be to allow this kind of offloading to pure JS functions instead of requiring hacky intercepts. You would still have a clear separation of responsibilities between frontend rendering (by the browser only) and application logic (which only generates HTML as output).
    - nymanjon 3y ago
      I've done the same thing with vanilla JS in a service worker. I did it with my HTMF library -- similar to HTMX -- but not production ready and based on forms rather than being able to put your attributes everywhere. I'll have to create a simple to do app with HTMX that shows this same functionality. The Rust one is cool as you can do it with 150kB library. But I can do the same thing with 10kB with just simple JS.
- _heimdall 4y ago
  Serverless and static are different. Static sites will likely be limited to maintaining state in the browser. Serverless is terribly named but still have a short lived server with access to request query parameters, cookies, headers, and a database depending on your setup

I hate HATEOAS with a passion. Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot. If htmx has anything to do with HATEOAS it's going to be ignored out of principle.

_heimdall 4y ago
Mind sharing why you have such strong opinions on HATEOAS? Is you problem that there aren't many implementations of it today or concerns with the architecture itself?
recursivedoubts 3y ago
That's because you are using in a JSON API context, where it doesn't make any sense. HATEOAS (or, as Fielding prefers to call it, the hypermedia constraint) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up. I try to explain why this is here: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... and I try to explain what HATEOAS really is here: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ and I try to explain why HATEOAS has been, by and large, a failure outside of true hypermedia clients presenting directly to humans here: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

ukuina 4y ago

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible? In a serverless read-only app, all business logic and state is maintained on the browser.

decross 3y ago
You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service https://github.com/richardanaya/wasm-service
- ukuina 3y ago
  This is cool! A possible extension to HTMX would be to allow this kind of offloading to pure JS functions instead of requiring hacky intercepts. You would still have a clear separation of responsibilities between frontend rendering (by the browser only) and application logic (which only generates HTML as output).
  - nymanjon 3y ago
    I've done the same thing with vanilla JS in a service worker. I did it with my HTMF library -- similar to HTMX -- but not production ready and based on forms rather than being able to put your attributes everywhere. I'll have to create a simple to do app with HTMX that shows this same functionality. The Rust one is cool as you can do it with 150kB library. But I can do the same thing with 10kB with just simple JS.
_heimdall 4y ago
Serverless and static are different. Static sites will likely be limited to maintaining state in the browser. Serverless is terribly named but still have a short lived server with access to request query parameters, cookies, headers, and a database depending on your setup