8 ms·

No one appreciates this tide reversal back towards hateoas principles and semantic HTML more than me, but why does it always come with prescriptions to adopt so

No one appreciates this tide reversal back towards hateoas principles and semantic HTML more than me, but why does it always come with prescriptions to adopt some new tech? You can implement all this stuff using literally any framework from the past 15 years if you want.

djeastm 2y ago
>You can implement all this stuff using literally any framework from the past 15 years if you want. Do you want to do that? I'd rather use what other people have done
yawaramin 2y ago
Yes, and htmx is basically intercooler.js with jQuery ripped out and some attributes renamed. Intercooler.js is one of these 'framework[s] from the past 15 years' that you referred to.
jph00 2y ago
The unique and very special aspect of HTMX's approach is that it changes just 4 things in browser behavior (list from the Hypermedia book): - Any element should be able to make HTTP requests - Any event should be able to trigger an HTTP request - Any HTTP Action should be available - Any place on the page should be replaceable The default behavior of browsers (without HTMX) is that only A and FORM tags can make requests, only GET (A,FORM) and POST (FORM) HTTP actions are available, only click can trigger a request, and only the full can be replaced. By changing these 4 things, it opens up a huge range of possibilities, but requires learning very few new concepts. And it also lets you work in whatever language you're most comfortable with -- you don't generally have to use JS (e.g very useful for data scientists, who generally know python).
- Sephr 2y ago
  The changes you're describing are already here in standard HTML + JS. Every element can be replaced with custom Web Components that can cause requests. Content can be partially displayed with just a click, tap, keypress, etc. and it doesn't even require scripting! There are over 200 extant discrete methods that can be used to send network requests in web applications running in modern browsers.
  - TibbityFlanders 2y ago
    [dead]
  - naasking 2y ago
    Except with htmx you don't have to leave your declarative html and dig into a whole other language.
    - sapling-ginger 2y ago
      You might want to read the TFA, it's describing a "whole other language" they call Hyperscript on click send htmx:abort to #contacts-btn on htmx:beforeRequest from #contacts-btn remove @disabled from me on htmx:afterRequest from #contacts-btn add @disabled to me
      - mega_tux 2y ago
        Hyperscript is totally optional, you can use vanilla js or something like alpinejs for extra stuff
      - recursivedoubts 2y ago
        hyperscript is a completely separate technology from htmx, it is designed to be an alternative to javascript and is very speculative htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like: AlpineJS, hyperscript (if you are brave), vanilla js, etc.
        troupo 2y ago
        All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.  <div hx-get="/example" hx-swap="innerHTML show:#another-div:top"> Get Some Content </div>  <div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div>  <div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'> <input type="text" /> </div>  <button hx-get="/info" hx-on::before-request="alert('Making a request!')"> Get Info! </button> <button hx-get="/info" hx-on="htmx:beforeRequest: alert('Making a request!') htmx:afterRequest: alert('Done making a request!')"> Get Info! </button> And so on.
- RodgerTheGreat 2y ago
  The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary. To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.
  - wild_egg 2y ago
    > every single interaction requires a separate round-trip HTTP request Why? It's not like JavaScript stopped existing. If you need something more interactive or dynamic, use JS. The two approaches are not exclusive. Some things can go to the server and some stay in the client. Your use case determines the balance. Easy.
    - karmarepellent 2y ago
      Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend. Well, you don't. I have been very successful using htmx by using it only in interactions that make changes to my data, that is state. Other user interactions (e.g. strictly visual interactions) remain on the client.
  - jph00 2y ago
    Quite the opposite, at least in some cases. The state lives in the HTML itself, and actual dev reports of large systems rewrites from react to htmx show faster systems as a result, not slower. In practice, it depends on what you're doing with it -- there isn't one right answer for all systems.
  - hipadev23 2y ago
    You’re absolutely incorrect.
  - p_l 2y ago
- wmanley 2y ago
  It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.
  - recursivedoubts 2y ago
    save the best for last! from the book: > This gives us our fourth, final and perhaps most important opportunity to generalize HTML: Opportunity 4 > HTML could be extended to allow the responses to requests to replace elements within the current document, rather than requiring that they replace the entire document. > This is actually a very old concept in hypermedia. Ted Nelson, in his 1980 book “Literary Machines” coined the term transclusion to capture this idea: the inclusion of content into an existing document via a hypermedia reference. If HTML supported this style of “dynamic transclusion,” then Hypermedia-Driven Applications could function much more like a Single Page Application, where only part of the DOM is updated by a given user interaction or network request.
recursivedoubts 2y ago
The book starts out with a history of hypermedia, a deep dive on the components of a hypermedia system and then a Web 1.0 style application built entirely in Flask. It then incrementally improves this with htmx, because htmx extends HTML in a specific way: it generalizes hypermedia controls. It considers how to integrate scripting and JSON APIs into a hypermedia driven application. It then showcases Hyperview (https://hyperview.org https://hyperview.org) a novel hypermedia system for mobile application development. You can't implement things like infinite scroll or active search in plain HTML because plain HTML only supports hypermedia exchanges based on two hypermedia controls, links & forms, with two events, clicks and submits, and your target options are limited to the current window, an new window, iframes and a few other obscure options. htmx generalizes this, allowing you to implement more dynamic user interfaces within the hypermedia paradigm.
dgb23 2y ago
Htmx is a very small, mostly AJAX related library with a nice structure that helps you do this in a principled way. There’s nothing special about it other thab doing pretty much exactly what you’d want.

djeastm 2y ago

>You can implement all this stuff using literally any framework from the past 15 years if you want. Do you want to do that? I'd rather use what other people have done

yawaramin 2y ago

Yes, and htmx is basically intercooler.js with jQuery ripped out and some attributes renamed. Intercooler.js is one of these 'framework[s] from the past 15 years' that you referred to.

jph00 2y ago

The unique and very special aspect of HTMX's approach is that it changes just 4 things in browser behavior (list from the Hypermedia book): - Any element should be able to make HTTP requests - Any event should be able to trigger an HTTP request - Any HTTP Action should be available - Any place on the page should be replaceable The default behavior of browsers (without HTMX) is that only A and FORM tags can make requests, only GET (A,FORM) and POST (FORM) HTTP actions are available, only click can trigger a request, and only the full can be replaced. By changing these 4 things, it opens up a huge range of possibilities, but requires learning very few new concepts. And it also lets you work in whatever language you're most comfortable with -- you don't generally have to use JS (e.g very useful for data scientists, who generally know python).

Sephr 2y ago
The changes you're describing are already here in standard HTML + JS. Every element can be replaced with custom Web Components that can cause requests. Content can be partially displayed with just a click, tap, keypress, etc. and it doesn't even require scripting! There are over 200 extant discrete methods that can be used to send network requests in web applications running in modern browsers.
- TibbityFlanders 2y ago
  [dead]
- naasking 2y ago
  Except with htmx you don't have to leave your declarative html and dig into a whole other language.
  - sapling-ginger 2y ago
    You might want to read the TFA, it's describing a "whole other language" they call Hyperscript on click send htmx:abort to #contacts-btn on htmx:beforeRequest from #contacts-btn remove @disabled from me on htmx:afterRequest from #contacts-btn add @disabled to me
    - mega_tux 2y ago
      Hyperscript is totally optional, you can use vanilla js or something like alpinejs for extra stuff
    - recursivedoubts 2y ago
      hyperscript is a completely separate technology from htmx, it is designed to be an alternative to javascript and is very speculative htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like: AlpineJS, hyperscript (if you are brave), vanilla js, etc.
      - troupo 2y ago
        All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.  <div hx-get="/example" hx-swap="innerHTML show:#another-div:top"> Get Some Content </div>  <div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div>  <div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'> <input type="text" /> </div>  <button hx-get="/info" hx-on::before-request="alert('Making a request!')"> Get Info! </button> <button hx-get="/info" hx-on="htmx:beforeRequest: alert('Making a request!') htmx:afterRequest: alert('Done making a request!')"> Get Info! </button> And so on.
RodgerTheGreat 2y ago
The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary. To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.
- wild_egg 2y ago
  > every single interaction requires a separate round-trip HTTP request Why? It's not like JavaScript stopped existing. If you need something more interactive or dynamic, use JS. The two approaches are not exclusive. Some things can go to the server and some stay in the client. Your use case determines the balance. Easy.
  - karmarepellent 2y ago
    Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend. Well, you don't. I have been very successful using htmx by using it only in interactions that make changes to my data, that is state. Other user interactions (e.g. strictly visual interactions) remain on the client.
- jph00 2y ago
  Quite the opposite, at least in some cases. The state lives in the HTML itself, and actual dev reports of large systems rewrites from react to htmx show faster systems as a result, not slower. In practice, it depends on what you're doing with it -- there isn't one right answer for all systems.
- hipadev23 2y ago
  You’re absolutely incorrect.
- p_l 2y ago
wmanley 2y ago
It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.
- recursivedoubts 2y ago
  save the best for last! from the book: > This gives us our fourth, final and perhaps most important opportunity to generalize HTML: Opportunity 4 > HTML could be extended to allow the responses to requests to replace elements within the current document, rather than requiring that they replace the entire document. > This is actually a very old concept in hypermedia. Ted Nelson, in his 1980 book “Literary Machines” coined the term transclusion to capture this idea: the inclusion of content into an existing document via a hypermedia reference. If HTML supported this style of “dynamic transclusion,” then Hypermedia-Driven Applications could function much more like a Single Page Application, where only part of the DOM is updated by a given user interaction or network request.

recursivedoubts 2y ago

The book starts out with a history of hypermedia, a deep dive on the components of a hypermedia system and then a Web 1.0 style application built entirely in Flask. It then incrementally improves this with htmx, because htmx extends HTML in a specific way: it generalizes hypermedia controls. It considers how to integrate scripting and JSON APIs into a hypermedia driven application. It then showcases Hyperview (https://hyperview.org https://hyperview.org) a novel hypermedia system for mobile application development. You can't implement things like infinite scroll or active search in plain HTML because plain HTML only supports hypermedia exchanges based on two hypermedia controls, links & forms, with two events, clicks and submits, and your target options are limited to the current window, an new window, iframes and a few other obscure options. htmx generalizes this, allowing you to implement more dynamic user interfaces within the hypermedia paradigm.

dgb23 2y ago

Htmx is a very small, mostly AJAX related library with a nice structure that helps you do this in a principled way. There’s nothing special about it other thab doing pretty much exactly what you’d want.