7 ms·

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 s

by 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.
        dartos 2y ago
        The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.
        troupo 2y ago
- sahil-kang 2y ago
  If I understand correctly, the main selling point of htmx is that _html_ is extended with the attributes from GP: the idea being that a bulk of the interactivity of SPAs can be achieved via hypertext alone I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"
  - noduerme 2y ago
    Which begs the question: Why mix logic with templates?
    - recursivedoubts 2y ago
      htmx mixes logic with "templates" in the same manner that HTML mixes logic with templates: hypermedia control information is embedded in the hypermedia in the form of attributes
      - noduerme 2y ago
        Maybe I should clarify the type of logic I mean. Standard HTML contains instructions for how content should be rendered. But it has no control flow structures to control what content should be rendered. Embedding loops and if/else logic in htmx tags creates scenarios where the content is potentially modified in the rendering step, meaning you can't rely on just looking at the data the backend sent over the wire to determine the source of a result that renders incorrectly. Instead of having control flow in one place, and a single source of truth, it creates an additional point of failure. Stock price showing up wrong? That might now be a problem in your backend logic or in your complex htmx engine, buried in some template tag.
    - sahil-kang 2y ago
      I think this htmx essay [1] addresses the tradeoffs you may be getting at if you're thinking "why html vs js+json": the gist is that html is self-describing to the browser, so the backend can make changes to the html it produces and the browser will understand it without the frontend code needing to be updated If you're instead thinking more broadly in terms of "structure vs layout", I think the same reasoning for using something like tailwind css or higher-level web components may apply: i.e. the material you interact with is closer to your problem domain [1] https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/two-approaches-to-decoupling/
- _heimdall 2y ago
  Accessibility is a royal pain in the ass if you replace every built-in element with a custom element. We'd be in a much better spot if browsers supported extending the built-ins. Without that, every custom element can only extend HTMLElement and all accessibility features in things like select menus are entirely up to you to reimplement.
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.

by jph00 2y ago

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.
      - dartos 2y ago
        The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.
        troupo 2y ago
sahil-kang 2y ago
If I understand correctly, the main selling point of htmx is that _html_ is extended with the attributes from GP: the idea being that a bulk of the interactivity of SPAs can be achieved via hypertext alone I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"
- noduerme 2y ago
  Which begs the question: Why mix logic with templates?
  - recursivedoubts 2y ago
    htmx mixes logic with "templates" in the same manner that HTML mixes logic with templates: hypermedia control information is embedded in the hypermedia in the form of attributes
    - noduerme 2y ago
      Maybe I should clarify the type of logic I mean. Standard HTML contains instructions for how content should be rendered. But it has no control flow structures to control what content should be rendered. Embedding loops and if/else logic in htmx tags creates scenarios where the content is potentially modified in the rendering step, meaning you can't rely on just looking at the data the backend sent over the wire to determine the source of a result that renders incorrectly. Instead of having control flow in one place, and a single source of truth, it creates an additional point of failure. Stock price showing up wrong? That might now be a problem in your backend logic or in your complex htmx engine, buried in some template tag.
  - sahil-kang 2y ago
    I think this htmx essay [1] addresses the tradeoffs you may be getting at if you're thinking "why html vs js+json": the gist is that html is self-describing to the browser, so the backend can make changes to the html it produces and the browser will understand it without the frontend code needing to be updated If you're instead thinking more broadly in terms of "structure vs layout", I think the same reasoning for using something like tailwind css or higher-level web components may apply: i.e. the material you interact with is closer to your problem domain [1] https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/two-approaches-to-decoupling/
_heimdall 2y ago
Accessibility is a royal pain in the ass if you replace every built-in element with a custom element. We'd be in a much better spot if browsers supported extending the built-ins. Without that, every custom element can only extend HTMLElement and all accessibility features in things like select menus are entirely up to you to reimplement.

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.