4 ms·

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PATCH and DELETE available, which allows HTML to take advantage of the full range of HTTP actions htmx is a completion of HTML as a hypermedia, this is its design goal

benatkin 4y ago
Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.
- recursivedoubts 4y ago
  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 i encourage you to read the linked article, and, if it is interesting to you, the essays at https://htmx.org/essays https://htmx.org/essays, and then potentially https://hypermedia.systems https://hypermedia.systems
  - dlisboa 4y ago
    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.
    - recursivedoubts 4y ago
      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
  - replwoacause 4y ago
    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?
- renerick 4y ago
  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.
  - benatkin 4y ago
    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.
    - renerick 4y ago
      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. [1]: https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers
- csjh 4y ago
  SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.
  - benatkin 3y ago
    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.
tomhallett 4y ago
have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards? When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of those features natively. :)
- recursivedoubts 4y ago
  i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again
  - tomhallett 4y ago
    question - which parts of htmx would be better from an end-user-perspective if they were built into the browser? i assume "all features" might be a bit faster, but is there anything which would be night and day better if it wasn't a js library? the browser vendors have been more than happy to use experimental features to chart their own course, which I think can be a good thing to spawn innovation and healthy competition. (given the standards bodies will be slower and more prudent - similar to how python doesn't want "pedantic" to be part of python core, because that would hurt pedantic's innovation, not improve it) Maybe the way someone from the chrome team could tap into "business value" of "let's build these htmx features in chrome" would be that it allows developers to write "internal/developer/crud apps" where a "only supported in chrome" is acceptable.....
    - recursivedoubts 4y ago
      maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/ https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure

benatkin 4y ago

Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

recursivedoubts 4y ago
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 i encourage you to read the linked article, and, if it is interesting to you, the essays at https://htmx.org/essays https://htmx.org/essays, and then potentially https://hypermedia.systems https://hypermedia.systems
- dlisboa 4y ago
  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.
  - recursivedoubts 4y ago
    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
- replwoacause 4y ago
  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?
renerick 4y ago
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.
- benatkin 4y ago
  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.
  - renerick 4y ago
    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. [1]: https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers
csjh 4y ago
SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.
- benatkin 3y ago
  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.

tomhallett 4y ago

have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards? When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of those features natively. :)

recursivedoubts 4y ago
i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again
- tomhallett 4y ago
  question - which parts of htmx would be better from an end-user-perspective if they were built into the browser? i assume "all features" might be a bit faster, but is there anything which would be night and day better if it wasn't a js library? the browser vendors have been more than happy to use experimental features to chart their own course, which I think can be a good thing to spawn innovation and healthy competition. (given the standards bodies will be slower and more prudent - similar to how python doesn't want "pedantic" to be part of python core, because that would hurt pedantic's innovation, not improve it) Maybe the way someone from the chrome team could tap into "business value" of "let's build these htmx features in chrome" would be that it allows developers to write "internal/developer/crud apps" where a "only supported in chrome" is acceptable.....
  - recursivedoubts 4y ago
    maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/ https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure