Comment by Grimblewald | Hacker News Reader

Comment by Grimblewald | Hacker News Reader

Parent Full thread

It's been massive for me as well. I would say my web developmemt is best described as dabbling in web development, and I mostly do so for websites that cater to academic interests and conference / society managment and organising. So, relativly niche.

However, I think HTMX is a beauty. Fast, simple, and doesnt come with all the bloat and BS a JS heavy / JS first deployment comes with. I can quikckly build fast and responsive sites that cost visitors very little to use/interact with.

websites have less compatability issues now, load extremely fast (google web speed score from 60-80 to flat 100), and have fewer points of failure. Debugging is a breeze. Websites are no less pretty or useful for it. In fact, they look better now because time otherwise wasted on Js BS is now free to use to tinker with / improve aesthetic, or add new features.

I'm in love with HTMX. It feels like what the web should have always been. There's absolutly zero reason a random website, without my knowledge or consent, should be running extremely heavy compute and analytics on my own device. That should never have been possible/permissible in the first place.

HTMX is just as JS compute heavy. It's not magic.

How is htmx ‘just as JS compute heavy’? It’s doing way less than your average SPA. Have you seen the sizes of the JS bundles of popular SPAs? They make htmx look microscopic in comparison.

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

yeah if that's a problem you can always use fixi https://github.com/bigskysoftware/fixi

What does that have to do with anything? Literally the same thing (only difference is size)

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

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.

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.

The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.

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.

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.

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

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.

A reminder. I was told things just work: https://news.ycombinator.com/item?id=49071380

And now you're repeating what I already said and somehow pretending it's an argument with something I didn't say.

No, you were told ‘the things work’, with progressive enhancement. Like many frontend things, progressive enhancement isn’t automatic with htmx. But it’s relatively easy and best of all works with any web server, not just JavaScript backends. Your criticism is basically that it’s not perfect, so it’s worthless. No, it works great for many use cases. And your judgement is clouded by your biases.

Let's see the fuller context:

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

> The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.

Oh. It turns out things don't work, neither on HTMX's own site, nor on most sites built with it.

Why do you keep arguing theory when reality is right there for anyone to see?

> Your criticism is basically that it’s not perfect, so it’s worthless.

No. My criticism is that HtMX authors and proponents keep presenting HTMX as something it objectively isn't despite actual verifiable reality.

I literally said what I mean in my first comment which started this pointless thread.

As I said in a sibling comment:

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

You inferred ‘reality’ by looking at examples that agree with your argument and ignoring ones that don’t. This is not theory, we have actually built this stuff. We’ve been telling you this over and over again. A couple of hand-picked counter-examples doesn’t change that.

Good luck with your confirmation bias fallacies though.

> 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 :-)

You're saying we need magic for different js frameworks to have different performance profiles?

Reply on news.ycombinator.com