if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach.
what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly.
it is a different approach to building web applications than the JSON/RPC style that is popular today
You’ve mentioned unpoly in a couple of your comments. I’m a beginner dev and have used HTMX successfully and quite easily, so thank you for making it. What does it offer that Unpoly doesn’t and vice-versa? Or do they basically do the same things?
I don't really see how progressive enhancement works if every element is a hypermedia control. Without JS/HTMX you just have a page that does nothing:
<div hx-get="/example">Get Some HTML</div>
This will never do anything without HTMX because the semantic of that markup is wrong. You'd really have to write everything in a vanilla HTML approach to begin with, and never make use of the idea of adding hypermedia to other elements.
you do have to structure things properly to make progressive enhancement work with htmx
for your example, you wouldn't have a div, you'd use an anchor:
<a hx-get="/example" href="/example">Get Some HTML</a>
or, more likely, just boost it:
<a hx-boost="true" href="/example">Get Some HTML</a>
and then on the server side you'd need to check the `HX-Request` header to determine if you were going to render an entire page or just some partial bit of HTML
if you go down the progressive enhancement route you need to think carefully about each feature you implement and how to make it compatible w/ no-js. Some patterns (e.g. active search) work well. Others (drag and drop) don't and you'll have to forgo them in the name of supporting noJS
nb: unpoly is a more seamless progressive enhancement experience due to its design goals
HTML forms absolutely do function without htmx since it's a part of browser standard. By default, htmx sends forms using same content type as browser does (application/x-www-form-urlencoded). The server will receive same requests, as if the browser sent them and can differentiate by presence of HX-Request HTTP header.
That's the properly part. If you make a form and the output is supposed to go in a particular place and it doesn't (hx-swap), then it isn't functioning properly. The degree to which it is improperly functioning depends on the UI and the user. In many cases it's improperly enough that it may as well either work or not work.
As mentioned, htmx will attach a `HX-Request: true` header to the request[1]. The server can check this header and either return a partial for swapping, or a full page/redirect like in good old days. Same with any request. This is one way of how htmx provides "progressive enhancement". Sure, this may not be as transparent, as other JS-first frameworks implement it, but it's not complex at all.
The only thing that might cause trouble is non-standard (as in HTML standard) HTTP methods, which basically means any method other than GET and POST, I admit that. However, the fact that these methods are not supported even in HTML5 is a huge miss.
I know they work at some level. That's why I'm comparing them to HTMX.
They don't work fine if the users/stakeholders don't find it acceptable to render the result to the full window instead of the hx-swap style area, or to spend extra time on the backend making it render the whole thing.
Actually, this is one area were SvelteKit has it beat, because the backend is done by SvelteKit, and you don't have to manually deal with hx-swap not taking effect.
Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.