Comment by yawaramin | Hacker News Reader

Comment by yawaramin | Hacker News Reader

Parent Full thread

> 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

Ok, take a look at the other popular frontend frameworks out there and tell me with a straight face that they don’t have their own mini-DSLs:

https://docs.solidjs.com/concepts/control-flow/conditional-r...

https://vuejs.org/guide/essentials/template-syntax.html

https://angular.dev/guide/templates#differences-from-standar...

None of which work with JavaScript turned off (unless you have a JavaScript backend and you wire it up to serve HTML).

The criticisms I’m seeing here are all things that are accepted without question in other frameworks but when htmx does it, suddenly it’s too much.

> The criticisms I’m seeing here are all things that are accepted without question

Who said they are accepted without question?

> when htmx does it, suddenly it’s too much.

No, when HTMX and its proponents claim things that are objectively provably false, it's too much.

Me: HTMX requires the server to be compliant with its DSL to work properly

You: no it doesn't. It's literally how content negotiation works! <Thus admitting HTMX requires server to conform to HTMX to work properly>

Me: there are literal standard headers for content negotiation

You: but what about React, and other frameworks.

Are we talking about React? Or other frameworks? We are talking about HTMx and your and others' claims about it.

Me: HTMX is custom templates and custom DSL.

You: no it's not!

Me: yes, it is

Me: It's standards compliant custom attributes and custom DSL. Why don't you look at all these other frameworks.

At every step of your "argument" you keep confirming every word I'm saying while somehow presenting it as an argument.

Try to actually learn something about tech you so fervently defend and to see how uour claims rarely differ from marketing bullshit (that marketing bullshit is often peddled by HTMx itself, most other frameworks are much more honest).

At this point I'm tired of pointless arguing with reality-denying people.

Adieu.

Htmx functions fine with any standard HTTP server in basic cases: it’s just an HTTP request and response with an HTML fragment. For progressive enhancement cases you can follow a very simple strategy of checking the HX-Request header and rendering either a full page or a partial, and adding a Vary: HX-Request response header. There’s no material difference between this and the standard content negotiation we talked about. To the server this is the same logic with just different names.

Also I pointed out that HTML already has custom DSLs in many of its attributes, this is not some new thing that htmx invented.

Finally, it says directly on the htmx landing page that it uses attributes for its functionality, and directly shows examples of common ones. This is right on the landing page. You have to dig into the special syntaxes of the other frameworks I mentioned to understand the differences they introduce. So I firmly refute your claims of marketing bullshit and dishonesty :-)

Try re-examining your own biases, you are in strong reality-warping mode :-)

Reply on news.ycombinator.com