undefined | Better HN

0 pointsrecursivedoubts3y ago0 comments

0 comments

7 comments · 2 top-level

ukuina3y ago· 3 in thread

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.

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

decross3y 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

ukuina3y 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).

1 more reply

lakomen3y ago· 2 in thread

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.

recursivedoubtsOP3y 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-opposi...

and I try to explain what HATEOAS really is here:

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.h...

_heimdall3y 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?

j / k navigate · click thread line to collapse

0 comments

7 comments · 2 top-level

ukuina3y ago· 3 in thread

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.

_heimdall3y ago

decross3y 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

ukuina3y 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).

1 more reply

lakomen3y ago· 2 in thread

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.

recursivedoubtsOP3y 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-opposi...

and I try to explain what HATEOAS really is here:

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.h...

_heimdall3y 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?

j / k navigate · click thread line to collapse