4 ms·

I looked at HATEOAS a few years ago and thought it would make sense in a latency-free universe. The reality is that waiting for one page to load to know what's

I looked at HATEOAS a few years ago and thought it would make sense in a latency-free universe. The reality is that waiting for one page to load to know what's next and then waiting again, is a recipe for bad frustratingly slow interactions. Shouldn't we download the whole application "graph" schema upfront? How big could that be?

recursivedoubts 5y ago
The browser has a built in bit of software called "the rendering engine" which turns HTML strings into visual widgets surprisingly quickly. A javascript application will still need to render to HTML. The few additional attributes necessary for an href are round off errors in the overall scheme of things. I would note that HATEOAS was simply a description of the world wide web. So, in as much as the web worked and continues to work, latency-free universe or not, it appears to be practical for building software systems.
- javajosh 5y ago
  >The browser has a built in bit of software called "the rendering engine"... FYI if you want to advocate for something, it helps not to condescend to the people you're advocating to.
dragonwriter 5y ago
> I looked at HATEOAS a few years ago and thought it would make sense in a latency-free universe. It makes perfect sense in a latency-laden universe; see, e.g., the Web. > Shouldn't we download the whole application "graph" schema upfront? How big could that be? Arbitrarily large. And it can become stale arbitrarily quickly. But, anyway, HATEOAS is consistent with that if you need it (consider the case where the application data is in a single document and individual resources are accessed by fragment identifiers for one simple example.)
raihansaputra 5y ago
I think this is a spectrum, currently with 2 approaches. The SPA routes mean every client side interaction is responded directly by the app, but still waits for the network. Client needs to download the whole application "graph" though. The HTML way means it doesn't "respond" for the latency period. But with modern tools (like HTMX/Hotwire/Unpoly), devs can start with HTML, and preload certain interactions/use minimal client side JS, instead of delegating all of it into an SPA. E.g.: Client side search/filter https://twitter.com/htmx_org/status/1459549924014669825 https://twitter.com/htmx_org/status/1459549924014669825
panick21_ 5y ago
HATEOAS does not constrain you about that. You can easily return composite pages and have links inside of the local context. There is a reason why html has page internal links. In fact its exactly designed in a way so that you can return one page that already has other stuff inside, and then the client can decide what of that to render. The server can even tell it not to render certain things.
hliyan 5y ago
If you calculate the size difference between JSON and a corresponding well-structured HTML/XML (i.e. without unnecessary nested divs), you will find that the extra network overhead is negligible. Modern SPAs still require network calls for most meaningful interactions. We can use Ajax calls to fetch partial HTMLs and replace target elements (like HTMX does).

recursivedoubts 5y ago

The browser has a built in bit of software called "the rendering engine" which turns HTML strings into visual widgets surprisingly quickly. A javascript application will still need to render to HTML. The few additional attributes necessary for an href are round off errors in the overall scheme of things. I would note that HATEOAS was simply a description of the world wide web. So, in as much as the web worked and continues to work, latency-free universe or not, it appears to be practical for building software systems.

javajosh 5y ago
>The browser has a built in bit of software called "the rendering engine"... FYI if you want to advocate for something, it helps not to condescend to the people you're advocating to.

dragonwriter 5y ago

> I looked at HATEOAS a few years ago and thought it would make sense in a latency-free universe. It makes perfect sense in a latency-laden universe; see, e.g., the Web. > Shouldn't we download the whole application "graph" schema upfront? How big could that be? Arbitrarily large. And it can become stale arbitrarily quickly. But, anyway, HATEOAS is consistent with that if you need it (consider the case where the application data is in a single document and individual resources are accessed by fragment identifiers for one simple example.)

raihansaputra 5y ago

I think this is a spectrum, currently with 2 approaches. The SPA routes mean every client side interaction is responded directly by the app, but still waits for the network. Client needs to download the whole application "graph" though. The HTML way means it doesn't "respond" for the latency period. But with modern tools (like HTMX/Hotwire/Unpoly), devs can start with HTML, and preload certain interactions/use minimal client side JS, instead of delegating all of it into an SPA. E.g.: Client side search/filter https://twitter.com/htmx_org/status/1459549924014669825 https://twitter.com/htmx_org/status/1459549924014669825

panick21_ 5y ago

HATEOAS does not constrain you about that. You can easily return composite pages and have links inside of the local context. There is a reason why html has page internal links. In fact its exactly designed in a way so that you can return one page that already has other stuff inside, and then the client can decide what of that to render. The server can even tell it not to render certain things.

hliyan 5y ago

If you calculate the size difference between JSON and a corresponding well-structured HTML/XML (i.e. without unnecessary nested divs), you will find that the extra network overhead is negligible. Modern SPAs still require network calls for most meaningful interactions. We can use Ajax calls to fetch partial HTMLs and replace target elements (like HTMX does).