[HN Gopher] The Hypermedia-Driven Application (HDA) Architecture
___________________________________________________________________
The Hypermedia-Driven Application (HDA) Architecture
Author : recursivedoubts
Score : 88 points
Date : 2022-02-06 15:16 UTC (7 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| no_wizard wrote:
| Other than returning html responses and the proprietary hyper
| script format how is this difference from something like API
| Platform[0]? The unspoken claim is you can't do the same thing
| with an SPA yet that shows you can.
|
| [0]: https://api-platform.com/
| no_wizard wrote:
| Can't edit this apparently, so this is what I really mean:
|
| I understand the appeal of what they are laying out here. I'm
| just wondering why the htmx approach has more benefits over the
| HATEOAS approach of something like API Platform that I linked
| to, which doesn't have any opinion on something being an MPA,
| SPA, or something in between
|
| Also to clarify: I mean proprietary as in proprietary to htmx,
| this is a poor word choice on my part, no different to how Vue
| has its Single File Components which are "proprietary" to Vue.
| I'm specifically trying to understand the advantage of
| something that ties your APIs to markup rather than using an
| interchange format such as JSON, as such when building scalable
| systems it not uncommon to need some form of interchange
| functionality. Even at a smallish company I work for we need to
| make sure it is digestible on web, and mobile applications.
|
| I'm just trying to apply some intellectual rigor to the model,
| as something I do think about is scaling, not say, Instagram
| Scale, even just something like a company with a 100+ million
| ARR may bubble these concerns
| murkt wrote:
| Haven't seen API Platform, can't compare to it.
|
| We can easily create endpoints that will respond with JSONs
| for mobile apps and with partial HTML for our hypermedia-
| driven application. The code is the same, just in the end
| check headers and render a template if we need to.
| ledgerdev wrote:
| There is absolutely nothing proprietary about the format. It's
| just plain html and vanillajs works fine if that's what you'd
| like to use. Hyperscript is no different than any other open
| source compile to js lang.
| transfire wrote:
| On one hand, I like the simplicity of it. On the other, I fear
| it's a backward move. We loose access to data as, well, data. If
| you get data from the backend it can be rendered in different
| ways by the front end. You loose that flexibility with HDA.
| recursivedoubts wrote:
| I recommend splitting your hypermedia and your data APIs up,
| because they end up having very different usage patterns:
|
| https://htmx.org/essays/splitting-your-apis/
|
| https://htmx.org/essays/hypermedia-apis-vs-data-apis/
| sdze wrote:
| You lose nothing. You just tell the backend by accept header
| what you expect it to return.
| jonathan-adly wrote:
| I have htmx running in production with a Django backend. It's
| honestly like having a cheat code for web development. Simple,
| scalable code that does the job perfectly!
| ledgerdev wrote:
| This exactly. I just started a new project with htmx this past
| week, and it absolutely amazing. It brings the magic of the web
| back we first experienced moving away from 90's windows
| programs. I'm a firm believer that react/angular are grossly
| mis-used for information based apps and websites, they should
| really only be used for rich client apps like chat, music
| players, image editors, offline, etc.
| murkt wrote:
| Image editors or offline stuff - sure. But even Chats and
| music players - there is not much going on in the browser.
|
| I'm using this approach (other library, though, which is
| called twinspark.js) for year and a half.
| throw_m239339 wrote:
| Context OP? What does that thing do that hasn't been done since
| the inception of Javascript and the DOM in the browser?
| ledgerdev wrote:
| Nothing totally new, but it is an attribute based extension of
| html that allows any element to generate http get/post and
| handle/target a hypermedia response back into the dom...
| without the need (but still have the option) to write
| javascript if you want. You end up writing almost zero js and
| it's wonderful.
| tomnipotent wrote:
| So each HTML element can have a a JS onclick handler (via
| htmx) that hits the server, which generates HTML, and the
| requesting page then uses JS to replace the instructed DOM
| node?
|
| This reminds me of the era before AJAX when we used to POST
| to a hidden iframe, and then JS in the hidden iframe would
| update the parent page.
| murkt wrote:
| This thing preserves your sanity!
| throw_m239339 wrote:
| I'm waiting for anyone to demonstrate me how this method
| isn't 3 step backward in 2022.
| murkt wrote:
| It is three step backwards. And one step to the side. Which
| is what I needed, and many others too.
| arbenpurben wrote:
| Damnit, I hate it when other people are more eloquent and
| on the money than me.
| murkt wrote:
| By far the biggest downside of this approach for me is
| that I found out about it in 2020 instead of 2013, when
| htmx predecessor was created (intercooler).
| mkl95 wrote:
| The hype around reactive technologies in the mid to late
| 2010s looks kinda funny now considering how much
| unwarranted hot garbage companies have built with it.
|
| But hindsight is 20/20. Someone may be building a
| beautiful language that will kill JS in the 2020s, and in
| 2026 we'll all be wondering why weren't using it in in
| early 2022.
| arbenpurben wrote:
| I mean this sincerely: can you demonstrate how using React
| et al for 95% of web apps (not talking about highly
| interactive stuff, offline-first or other special cases)
| was at all a step forward for web apps, OTHER than
| eliminating full page refreshes and thereby improving UX?
| Nevermind developer experience, although that is more
| subjective of course. The "decoupling" and "single JSON-
| based REST API for all clients", etc. arguments are nice in
| theory but impractical in reality. By all means have a
| JSON-based API for exactly that - application programming
| interfaces, not human-consumable interfaces. I would argue
| the development, deployment & maintainability complexity of
| those SPAs can not be justified for most web apps, if you
| are able to offer the essentially the same UX benefits with
| an HDA approach.
| jrochkind1 wrote:
| Compare to turbo/stimulus from Rails world; I would put the
| approach in the same basic category, that being: Custom HTML
| attributes triggering standardized behaviors, with HTML sent over
| the wire for partial page updates.
|
| I wonder what other platforms are going on right now in this same
| category -- anyone have more examples?
|
| And in general how much "mind share" (or really development-
| share) it's getting.
| nvegater wrote:
| Specifically this html attribute in the delete button: `hx-
| delete="/contact/1"`. where the id of that contact is 1 and it is
| hardcoded as a string.[0]
|
| How do I dynamically generate a list of deletable items? In react
| would be something like (simplified obviously) `contacts.map(c =>
| <button onClick={apiDelete(c.id)}/>`.
|
| I dont understand how could I generate dynamic lists without
| hardcoding Ids... is that a case where I would need to use normal
| vanilla js ?
|
| 0: https://htmx.org/examples/delete-row/
| recursivedoubts wrote:
| You generate all links on the server side, using Hypermedia As
| The Application of Engine State (HATEOAS):
|
| https://htmx.org/essays/hateoas/
| nvegater wrote:
| I went into the rabbit hole. There were 2 particularly useful
| links I found: https://htmx.org/essays/a-response-to-rich-
| harris/ https://htmx.org/examples/update-other-content/
|
| Very interesting developing tech philosophy. I was a bit in
| the js bubble for a while. Its refreshing to see such a
| simple and powerful idea/tech outside of it:)
| murkt wrote:
| Just generate these ids on the server. For example, when I
| render a new field for which I need a delete button, I send
| numbers of other fields along with them, and server renders a
| new field for me with a new id.
| nvegater wrote:
| Thanks for responding. If I understand correctly, then I
| would need a server like nodejs or django generating and
| sending the "index.htmx" to the browser and then responding
| to users interactions by embedding the data from the server
| inside of the htmx files, correct?
| murkt wrote:
| Sounds about right.
|
| It's the good old server templates (we use Jinja), and for
| interactivity I have additional attributes here and there,
| and sometimes additional endpoints.
|
| It's miles better than full-fledged JS SPA. I've had
| React+GraphQL app that I'm migrating piece by piece when we
| need a new feature, and it's a few times faster to do and
| easier to understand.
| shrimpx wrote:
| The core assumption of stacks like htmx is that you don't need
| fine-grained client-side interactions implemented in custom
| Javascript; that when you need the UI to change, it's ok to go
| through the server.
|
| An example edge case where this fails completely is a canvas-
| based interactive game, where you (a) cannot "ask the server for
| html" in order to update your game UI and (b) going through the
| server for every UI update is unacceptable for performance.
|
| That said, people are realizing that in a very large percentage
| of practical cases (i.e., CRUD apps), you do not need the high
| fidelity of javascript and you can skip a lot of the related
| complexity by using simplified stacks.
|
| The big fail would be if you use htmx at first but over time you
| end up grafting a bunch of custom JS on top anyway, and your
| backend is a complicated Jinja mess, which is what made old
| school Rails/Django projects total messes and caused people turn
| to SPAs + JSON pumps. It probably takes some discipline to stick
| with pure htmx and push back on requests to graft random crap on
| top.
| recursivedoubts wrote:
| Yes. Like any application architecture, the Hypermedia Driven
| Application architecture has strengths and weaknesses.
|
| In the case you outline, a canvas-based application, a
| hypermedia driven application is not going to be a good choice.
| However, that being said, it may be a good choice for _parts_
| of your application (e.g. the settings page.)
|
| Thankfully many SPA libraries are now embedable within an
| broader application, so you can use that approach when it fits
| best, and other, simpler approaches in other parts of your
| application.
| realrocker wrote:
| Agreed. I have been playing with the idea of escaping to use
| svelte in spots for finer interactions :
| https://github.com/adnaan/gomodest-template
| mkl95 wrote:
| I have mixed feelings about htmx. It's wonderful, but it's going
| to take years for companies in my area to know it exists. I will
| totally pick it for some personal project though.
| arbenpurben wrote:
| Be the change you want to see in the world :)
| recursivedoubts wrote:
| https://www.youtube.com/watch?v=tYzMYcUty6s
| arbenpurben wrote:
| We have htmx & hyperscript running in production powering a
| fintech saas. It is fantastic in the way that all really good
| technology is: it just does what it's supposed to do so simply
| and efficiently that you kinda forget it's there, so you end up
| spending time where it counts (UX and business logic), instead of
| fighting finicky frameworks. No-one in the real world cares about
| the supposedly great framework powering a web app - they just
| care that the app is fast, easy to use and saves them time and
| money.
| sdze wrote:
| I love your pragmatism.
| arbenpurben wrote:
| Thanks!
| melony wrote:
| Link to the SaaS?
___________________________________________________________________
(page generated 2022-02-06 23:00 UTC)