4 ms·

A few benefits of the hypermedia approach are: - It can be a much simpler approach to building an application. As evidence for this fact, consider Contexte's

A few benefits of the hypermedia approach are: - It can be a much simpler approach to building an application. As evidence for this fact, consider Contexte's experience moving from react to htmx for their Saas application: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/. They reduced their codebase to 1/3rd the size with no reduction in UX, dropped JS dependencies by 95%, etc. Not every project is this amenable to hypermedia, but many are. - Related to this, hypermedia is the "native" architecture of the web, and browsers have a lot of technology built into them for it. htmx is a depenedency-free 12k library because it builds on top of that model. - By adopting hypermedia as your system architecture, you push your logic back onto the server side, where you are free to use whatever programming language you prefer: clojure, python, haskell, etc. This lets you write more code in your preferred programming language and execution environment. - The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there. This is in contrast with the browser, where you can't have unrestricted access to the data store due to the fact that a hostile user can open a console and start manipulating the data store. On the server side, you can just use SQL. On the client side, you can't, without putting your whole data store at risk. There are certainly tradeoffs associated with the hypermedia approach: it doesn't work well in situations when you need to respond quickly to many UI-driven events, it sacrifices representational efficiency for flexibility, etc. There isn't a silver bullet, after all. With htmx I am trying to expand the set of applications for which the hypermedia approach will work, but I have no illusions that it will work for everyone: nothing is right for everything.

amw-zero 4y ago
> It can be a much simpler approach to building an application This is not related to hypermedia, this is related to server-rendering vs. client-rendering. Everyone knows that server-rendering saves on some code and JS. This is a tradeoff, for less control over the stateful aspects of the client. > Related to this, hypermedia is the "native" architecture of the web But, that was the text-based web. Hypermedia isn't necessary (or desired) for applications, which the web has moved towards supporting. > By adopting hypermedia as your system architecture, you push your logic back onto the server side Nothing to do with hypermedia. You can choose to push logic to the server with a single-page app too. > The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there Same. I'm still failing to see a _benefit_ that hypermedia and HATEOAS approach provides, or what problem it solves.

amw-zero 4y ago

> It can be a much simpler approach to building an application This is not related to hypermedia, this is related to server-rendering vs. client-rendering. Everyone knows that server-rendering saves on some code and JS. This is a tradeoff, for less control over the stateful aspects of the client. > Related to this, hypermedia is the "native" architecture of the web But, that was the text-based web. Hypermedia isn't necessary (or desired) for applications, which the web has moved towards supporting. > By adopting hypermedia as your system architecture, you push your logic back onto the server side Nothing to do with hypermedia. You can choose to push logic to the server with a single-page app too. > The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there Same. I'm still failing to see a _benefit_ that hypermedia and HATEOAS approach provides, or what problem it solves.