If there was an #HTML element that changes it's content when users interact with other elements on the page, what name would it have?
PLEASE NOTE: I am not suggesting that this element needs to exist; I am only asking what it would be called. I'm building a CustomElement, I just want it to have a name that makes sense.
Vote and suggest others in replies. Please boost for reach!
An <HTML> element that updates with the result of an HTTP request that some other element on the page made.
Links and forms inside it may be changed so that they only update this element instead of the whole page; similarly to Hotwire: TurboFrames https://turbo.hotwired.dev/handbook/frames
I'm really confused as to why this is so novel to those who comment here. #JSON was not even a part of #REST: it is usually not representing anything and is not self-explanatory. Clients somehow have to catch up to API changes all the time, and backend can go chill??? This must be an obvious flaw with #JSONAPI.
And yet, the concept of #hypermedia responses, that #HTMX and #HATEOAS try to remind us of, seems alien to most. Oof, now that's the power of gaslighting in development circles! :rickwhoah:
I'm only just finding my way in the land of #htmx, but it feels like "trigger a request from any #HTML element" is a trap. I want progressive enhancement, which still requires a functional non-Javascript page before adding the nice things htmx offers. I didn't realise how rusty I am with regard to designing a presentation layer for all this in the backend.
@_chrismay
Yeah I've been looking at that. Reading the HX-Request header to determine whether to give a full-page response or just a snippet is what I do, and it quickly made it clear that navigating my site structure needs more up-front attention. Which is pretty much in line with #HATEOAS I think.
When I got started in #webDev I used a lot of <forms> and when I learned about #REST I wondered why there was no way to generate PUT, PATCH, and DELETE #http verbs from #html
a) HTML attr based DSLs give me Angular flashbacks. It's declarative, but sometimes I think declarative is harder to grok than imperative.
b) if your UI change required a network request anyway (even if only for confirmation of success) then the performance is the same. but for minor UI state changes, you probably have a point.
@macdonst says that #HATEOAS can lead to network request bloat when you need to make a chain of multiple requests to get some resource.
htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext :picklerick: