Comment by yawaramin
10 hours 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.
> 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.
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.
Because 1) React is the only framework out there and b) that somehow absolves HTMX or makes anything I said untrue