4 ms·

It doesn’t have its own templating syntax, it just uses server side HTML generation. It doesn’t require the backend to ‘conform’ to anything, it works with very

It doesn’t have its own templating syntax, it just uses server side HTML generation. It doesn’t require the backend to ‘conform’ to anything, it works with very standard HTTP forms and HTML responses. I’m afraid you’re very confused!

troupo 3mo ago
> It doesn’t have its own templating syntax What do you think hx-get and hx-trigger="input changed delay:1s" are? Standard browser attributes? Standard browser functionality and behaviour? Standard events syntax? > It doesn’t require the backend to ‘conform’ to anything, Just one of the quotes from the docs: "You would need to check on the server side for the HX-Request header to differentiate between an htmx-driven and a regular request, to determine exactly what to render to the client." > I’m afraid you’re very confused! I'm afraid I'm not
- tailscaler2026 3mo ago
  That's how progressive enhancement works. The website should work fine if JS is disabled. Then it's faster via htmx if JS is enabled, and more so if the backend is tuned as well.
  - troupo 3mo ago
    None of the things HTMX adds will work. Which is easy to test by just turning off Javascript on most (any?) examples or sites using HTMX. Because none of that is standard, none of that is understood by browsers, and requires HTMX to work. Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly.
    - zamalek 3mo ago
      The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.
      - troupo 3mo ago
        Lol. Even the hamburger menu doesn't work on htmx.org without Javascript. I'll let you find any working examples yourself. Most sites won't work or will be broken, too. Obviously You have to actually try and work on progressive enhancement, and not rely on marketing blurbs and promises of magic. I wonder if people blindly defenfing their favorite thingd actually know anything about them.
        yawaramin 3mo ago
        Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated. It wouldn’t be difficult to make the hamburger menu work without any JS by just using the Popover API, which again is completely unrelated to htmx and can be used by any frontend framework. I assure you I know quite a bit more than you when it comes to htmx and progressive enhancement, having built multiple progressively enhanced htmx apps that work almost exactly the same without JS.
        troupo 3mo ago
        > Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated. Yup, the unworking hamburger menu on the website preaching about progressive enhancement and built entirely with this framework "has nothing to do with htmx". All examples on HTMX site that we're told will just work "with full page reload" and that don't work also have nothing to do with HTMX. HTMX is magical progressive enhancement "The things work, albeit with a full page load" somehow are broken on HTMX site itself and on most sites built with it, but all this also has nothing to do with it. Because "things just work"
        yawaramin 3mo ago
        The htmx website is full of demos showing how htmx works. Htmx is a JavaScript framework. Unsurprisingly, some of these demos don’t work when JavaScript is turned off. This thread is getting absurd now.
    - tailscaler2026 3mo ago
      [dead]
      - dang 3mo ago
        It's not ok to post like this here. Since it isn't the first time you've broken the rules like this, I've banned this account. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- yawaramin 3mo ago
  > What do you think hx-get and hx-trigger Hx-attributes are not a new ‘templating syntax’, they’re custom attributes with a simple DSL for describing triggers and swaps. You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant. HTML itself is full of these little in-attribute DSLs–look up the standard ‘autocomplete’ attribute: <textarea autocomplete="shipping street-address"></textarea> When people complain about this stuff, they just reveal they don’t know HTML. > …from the docs: "You would need to check on the server side for the HX-Request header… Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants and the server sends headers describing what it gives. I hope you’re not suggesting that htmx invented this technique. It’s kinda funny to suggest that htmx forces servers to ‘conform’ to something when most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes.
  - troupo 3mo ago
    > Hx-attributes are not a new ‘templating syntax’, They are. If you look at how they are processed by HTMX itself. > they’re custom attributes with a simple DSL At least you agree that it's a custom DSL > You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant. It doesn't matter if they are "standards compliant". The browser has literally no idea what they are, and what that DSL is. HTMX parses them, parses the DSL etc. Turn off Javascript and whatch how this beautiful standard-compliant stuff turns inert (or doesn't even load). > Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants That's not how content negotiation works. Standard content negotiation does not require custom headers, or the client needing to parse this header and be aware of anything to differentiate requests. There's are literal Content-Type and Accept standard headers. And yet HTMX invents its own flavor. > most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes. Most of which AFAIR don't require custom headers.
    - yawaramin 3mo ago
      You must be joking, React Flight Protocol for RSC is literally a new RPC system that comes with its own set of brand-new vulnerabilities. But sure, adding a couple of HTTP headers, which were designed for exactly this kind of use case (adding metadata to requests and responses), is a bridge too far.

troupo 3mo ago

> It doesn’t have its own templating syntax What do you think hx-get and hx-trigger="input changed delay:1s" are? Standard browser attributes? Standard browser functionality and behaviour? Standard events syntax? > It doesn’t require the backend to ‘conform’ to anything, Just one of the quotes from the docs: "You would need to check on the server side for the HX-Request header to differentiate between an htmx-driven and a regular request, to determine exactly what to render to the client." > I’m afraid you’re very confused! I'm afraid I'm not

tailscaler2026 3mo ago
That's how progressive enhancement works. The website should work fine if JS is disabled. Then it's faster via htmx if JS is enabled, and more so if the backend is tuned as well.
- troupo 3mo ago
  None of the things HTMX adds will work. Which is easy to test by just turning off Javascript on most (any?) examples or sites using HTMX. Because none of that is standard, none of that is understood by browsers, and requires HTMX to work. Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly.
  - zamalek 3mo ago
    The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.
    - troupo 3mo ago
      Lol. Even the hamburger menu doesn't work on htmx.org without Javascript. I'll let you find any working examples yourself. Most sites won't work or will be broken, too. Obviously You have to actually try and work on progressive enhancement, and not rely on marketing blurbs and promises of magic. I wonder if people blindly defenfing their favorite thingd actually know anything about them.
      - yawaramin 3mo ago
        Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated. It wouldn’t be difficult to make the hamburger menu work without any JS by just using the Popover API, which again is completely unrelated to htmx and can be used by any frontend framework. I assure you I know quite a bit more than you when it comes to htmx and progressive enhancement, having built multiple progressively enhanced htmx apps that work almost exactly the same without JS.
        troupo 3mo ago
        > Hamburger menu on the htmx.org site using JavaScript has nothing to do with htmx the framework itself, they’re completely unrelated. Yup, the unworking hamburger menu on the website preaching about progressive enhancement and built entirely with this framework "has nothing to do with htmx". All examples on HTMX site that we're told will just work "with full page reload" and that don't work also have nothing to do with HTMX. HTMX is magical progressive enhancement "The things work, albeit with a full page load" somehow are broken on HTMX site itself and on most sites built with it, but all this also has nothing to do with it. Because "things just work"
        yawaramin 3mo ago
        The htmx website is full of demos showing how htmx works. Htmx is a JavaScript framework. Unsurprisingly, some of these demos don’t work when JavaScript is turned off. This thread is getting absurd now.
  - tailscaler2026 3mo ago
    [dead]
    - dang 3mo ago
      It's not ok to post like this here. Since it isn't the first time you've broken the rules like this, I've banned this account. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
yawaramin 3mo ago
> What do you think hx-get and hx-trigger Hx-attributes are not a new ‘templating syntax’, they’re custom attributes with a simple DSL for describing triggers and swaps. You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant. HTML itself is full of these little in-attribute DSLs–look up the standard ‘autocomplete’ attribute: <textarea autocomplete="shipping street-address"></textarea> When people complain about this stuff, they just reveal they don’t know HTML. > …from the docs: "You would need to check on the server side for the HX-Request header… Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants and the server sends headers describing what it gives. I hope you’re not suggesting that htmx invented this technique. It’s kinda funny to suggest that htmx forces servers to ‘conform’ to something when most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes.
- troupo 3mo ago
  > Hx-attributes are not a new ‘templating syntax’, They are. If you look at how they are processed by HTMX itself. > they’re custom attributes with a simple DSL At least you agree that it's a custom DSL > You can prefix them with ‘data-‘ if you want and they will be 100% standards-conformant. It doesn't matter if they are "standards compliant". The browser has literally no idea what they are, and what that DSL is. HTMX parses them, parses the DSL etc. Turn off Javascript and whatch how this beautiful standard-compliant stuff turns inert (or doesn't even load). > Yes, this is how HTTP content negotiation works. The client sends headers to the server describing what it wants That's not how content negotiation works. Standard content negotiation does not require custom headers, or the client needing to parse this header and be aware of anything to differentiate requests. There's are literal Content-Type and Accept standard headers. And yet HTMX invents its own flavor. > most of today’s JS frameworks do server-side rendering only on JavaScript server runtimes. Most of which AFAIR don't require custom headers.
  - yawaramin 3mo ago
    You must be joking, React Flight Protocol for RSC is literally a new RPC system that comes with its own set of brand-new vulnerabilities. But sure, adding a couple of HTTP headers, which were designed for exactly this kind of use case (adding metadata to requests and responses), is a bridge too far.