← Back to context

Comment by troupo

16 hours ago

It's a 14kb library that invents its own templating syntax and DSL and also requires the backend to conform to its DSL.

Yes, it's smaller than some other frameworks, but let's stop with "doesn't require JS" nd other bullshit

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!

  • > 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

    • > 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.

      3 replies →

    • 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.

      9 replies →