Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
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 & submit events trigger them?
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
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.
EDIT: Put another way, if you look at HTMX’s "motivation"s:
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
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