6 ms·

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

• 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. <!-- Some kind of inline DSL in an attribute? Check --> <div hx-get="/example" hx-swap="innerHTML show:#another-div:top"> Get Some Content </div> <!-- Some kind of inline DSL that is sorta kinda JS? Check --> <div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div> <!-- Some kind of inline DSL that is marked as Javascript and with magic values passed in? Check --> <div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'> <input type="text" /> </div> <!-- Is it Javascript? Jinx, it's custom DSL --> <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
            That literally isn't what I talked about.
            • dartos 2y ago
              3 out of 4 of your examples mentioned using js or a js-like DSL. Explain your point better
              • troupo 2y ago
                It's enough to read the context of the discussion, don't you think? Original complaint: "it's describing a "whole other language" they call Hyperscript" Response: hyperscript is a completely separate technology. htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like My response: In reality [1] htmx defines its own non-optional DSL that you have to use. --- I will add that as with any organically grown nice-to-have utility DSLs it's quite haphazard (it's hyperscript-like in one place, js-like in another place, both in some other places etc.). But that's the nature of such ad-hoc informally specified DSLs [1] which can be easily verified by just visiting https://htmx.org https://htmx.org
• 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.