I'm confused. This is exactly what https://htmx.org/attributes/hx-target/ is for since they're already using htmx. This doesn't make sense to add to the html spec unless ajax requests themselves are added such that browsers will do this automatically. Which I don't think anyone wants.
this post was submitted on 16 Mar 2024
14 points (88.9% liked)
Programming
17313 readers
157 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
I think the point is that they don't want to have to use a full JS framework (which is what HTMX is) for this behavior.
And this is where HTMX fits in. It's an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.
But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.
EDIT: Put another way, if you look at HTMX's "motivation"s:
motivation
- Why should only
<a>&<form>be able to make HTTP requests?- Why should only
click&submitevents trigger them?- Why should only
GET&POSTmethods be available?- Why should you only be able to replace the entire screen?
By removing these constraints, htmx completes HTML as a hypertext
It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.
I see, I guess I get the point they're making. We can do iframe reloads based on clicks without javascript, why not div reloads. I think framing it as a way of doing this without javascript rather than without a framework would be clearer and a better argument
So here's what I propose (and what I've built as a small demo below):
They're suggesting it should be part of browser behaviour. They couldn't demonstrate it without JS.
Yeah, I missed the part where they wanted it to be built into the browser