yawaramin

Just do passkeys.

Htmx is not meant for these use cases. We’re building great interactive webapps with htmx using the web platform’s built-in capabilities. If you need exact scroll position and text highlighting you can get that with some other framework. Htmx works well with things that are in its own niche.

No, every interactive event doesn't need to have a network request in the loop. And you only need a tiny bit of client-side JS for a most of the plumbing.

It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.

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.

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

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.

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.

Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.

Maintenance burden, supply chain attacks and the constant dependency upgrade treadmill. With a very minimal footprint app, you can avoid all that to a large extent.

Can be done by updating the form fields dynamically as they are edited. Doesn’t need to be done all in one shot. Eg: on blur of each field, send an htmx request and update the other fields. On form submit with htmx, send only the results partial.

Htmx can work great with web components.

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.

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.

No they didn’t…they replaced whatever backend they had before with a Go server, which simplified things overall.

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.

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

That’s great, but unless you know some secret perfect technology that the rest of us don’t, every tech you use is also full of these workarounds, you just ignore them because you like the tech.

Also, hx-boost isn’t really a workaround, it’s a fully supported and documented feature.

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!

Htmx is actually quite good at graceful degradation IF you stick to hx-boost for most interactions. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

Your comment post endpoint already knows what page the comment is in, it’s in whatever page the ‘post a comment’ form is in. When we design apps in a way that respects the conventions of REST (hypermedia and resource-oriented design), htmx slots in perfectly.

Use tagged template literals. I wrote about it here https://news.ycombinator.com/item?id=48915935

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 concern because I use htmx for loading and updating resources and I want those operations to work as well as possible even without JavaScript. I’ve never felt the need for Alpine.js, I have very little I need to do with custom JS, and it’s trivial to maintain that by hand.

I wrote specifically about this, see https://news.ycombinator.com/item?id=48915935

Like F#...? https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

The problem with an anomalous AWS bill is that I don't know if it's because of a bug on their end or because of a goof on my end, eg did I accidentally leave on some giant compute for a month or something. With a billion in my bank account I at least know that I definitely didn't put it in there.

Last I checked Datastar doesn't support progressive enhancement. I like using <a href hx-boost=true> and <form method action hx-boost=true> so almost all my functionality works even without JavaScript. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

See https://news.ycombinator.com/item?id=48915935

Yeah, a data grid is a good example of a complex hyper-interactive component. There are people out there who have made them with Web Components, which can be dropped in and used in htmx projects when used correctly.

Re: request states, handled very nicely out of the box by htmx with a little knowledge of attributes like hx-indicator and JS event handlers to handle htmx error events.

You can use JSX but tagged template literals are supported out of the box by JS runtimes, so you wouldn’t need to add a build step.