Please just try HTMX - Hacker News

Posted by iNic 12/18/2025

Please just try HTMX(pleasejusttryhtmx.com)

616 points | 515 commentspage 4

zero0529 12/18/2025|

What I don’t like with HTMX and the like is that you basically don’t get any help in the backend. It also introduces implicit coupling between the frontend and backend which is very much the worst kind of coupling you can have. While this is fine for small to medium projects it is terrible in the long run.

To be honest this might be a skill issue or something I haven’t understood properly with these frameworks.

nicole_express 12/18/2025||

The big problem I have with HTMX is the same one I have with React server components and similar concepts; I really like being able to just serve static files. Plus the clear separation of server and client really makes reasoning about a lot of different problem cases a lot easier, that's not something to dismiss lightly. (It's a bit of a 'ship your org chart' case, though)

yawaramin 12/18/2025|

Htmx has very clear separation between server and client. The server is in your backend language and framework. The frontend is HTML.

mythz 12/18/2025||

I keep seeing articles religiously pushing htmx, what I'm not seeing are sophisticated examples or apps written with it, just more basic example and interaction examples.

I personally prefer UIs with great encapsulation/composition, which used to be Vue, but with AI starting to write more of my UIs now I've switched to React/Next.js for new non-progressive UIs.

purerandomness 12/18/2025||

Please install a TLS certificate to the site so people can view the content.

CompuHacker 12/18/2025||

The link doesn't point to an HTTPS server.

philipwhiuk 12/18/2025||

Exactly - it's on a short leash towards being blocked by browsers.

https://security.googleblog.com/2025/10/https-by-default.htm...

DaSHacka 12/18/2025||

There is a cert, it's just not signed by a CA.

g947o 12/18/2025|||

That's in some sense even worse than plain HTTP, because it gives you a false sense of security.

DaSHacka 12/19/2025||

Not really, modern browsers warn about self-signed certificates the same as HTTP (or sometimes even more). And obviously you can in theory verify the signature's fingerprint akin to a trust-on-first-use model like SSH.

May not be as standard as a CA model in the current landscape, but trust on first use has shown to be perfectly fine for SSH, and has the advantage that you're not trusting third parties to only sign valid certificates for authorized parties.

g947o 12/19/2025||

I think you lost the context

> modern browsers warn about self-signed certificates the same as HTTP

So if I can read and understand those browser warning and am not a complete idiot, I will close the browser tab instead of proceed despite the warning. Which is the correct choice.

So now I cannot read the website at all.

Otherwise, if I do make the bad decision and accept the certificate, I don't know what will happen. But with HTTP, at least the browser says clearly that the site is unsafe.

So the fact that the website does have a certificate and serves HTTPS, as suggested in the GP, is completely irrelevant and useless.

> trust on first use has shown to be perfectly fine for SSH

If that is MY server or a server I trust/can verify. I don't know about you, but I never SSH into someone else's server and just blindly accept the keys. GitHub, for example, provides their SSH keys: https://docs.github.com/en/authentication/keeping-your-accou...

yawaramin 12/18/2025|||

What are you guys talking about. It automatically redirects to the HTTPS version and the cert is signed by Let's Encrypt.

g947o 12/21/2025||

You are late to the party, and it's already fixed.

> It automatically redirects to the HTTPS version

That's your browsing doing the job, not how the site is set up.

yawaramin 12/21/2025||

Which browsers are not doing this?!

aembleton 12/18/2025||

> The server just returns HTML (not JSON, actual HTML)

Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable.

That way all of the front end code is in one place.

wvbdmp 12/18/2025||

But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.

aembleton 12/19/2025||

I'd rather have the often loaded static html running on a server that is optimised for that job, or served from a cache close to the user. The backend can then just serve up the dynamic content and be optimised for that job.

yawaramin 12/21/2025||

The 'often loaded' static html won't help if the 'often loaded' JS bundle is re-deployed (eg, when the devs make a 'small' change) and the cache is invalidated. In that case all the users will be forced to reload the giant JS bundle over and over again, as opposed to just reloading a single resource on a single page like they would with the htmx approach.

turtlebits 12/18/2025||

In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.

aembleton 12/18/2025||

Having the html stored both on a static html site that can be cached and in the code base of a backend server is more complex to me than keeping these concerns separate.

yawaramin 12/21/2025||

That's why you just have the HTML in the backend server codebase...which can also make sure it's cached properly with HTTP caching techniques like last modification time, ETag, and so on.

politelemon 12/18/2025||

The author seems to have some beef with angular, which I have found lighter and more pleasant to use compared to react.

mattlondon 12/18/2025|

Same here. Modern angular is pretty nice to work with.

Yes It has a "learning curve" but so does everything (even React).

Also Angular is now about twenty thousand times simpler than it was in the past as you can use Signals for reactivity, and basically ignore Observables for 95% of things.

Angular also removes the a lot of the negatives outlined in the page - no npm, no node_modules, no ecosystem fatigue, no debates on state management etc etc. Everything you need is included in one dependency you can load from a CDN.

I never liked that in react you are mangling the presentation and business logic in one tsx file (separation of concerns? React ignores that lesson for some reason). Htmx feels even worse in this way because now you also have html snippets and templates in your backend code too! Nightmare! Angular let's you leave the templates as standalone files and not mushed into your typescript like react (although you can inline them into the typescript if you want to, but obviously no one does that for anything apart from the most trivial of components)

codedokode 12/19/2025||

I looked at the code examples and instantly saw something familiar. I remember, there was a library that intercepted link clicks, made AJAX requests and updated DOM with response, so that the page would update without reloading. If for any reason the code failed, there was just standard link navigation so you could access the content any way. I think it was pjax library.

It made the site look like a SPA without having to write any extra code. How cool is that.

HTMX resembled me this library. But it seems very narrow cased, there are only so many attributes and their values and you cannot implement anything else. While pjax is generic: you can attach it to any site which has links.

Also you cannot replace Vue (don't use React) with HTMX. For example, if you are making a diagram editor, HTMX won't be useful.

mvdtnz 12/18/2025||

I haven't used HTMX but the author doesn't make a very convincing case. On the one hand they say,

> "But what about complex client-side state management?"

> You probably don't have complex client-side state. You have forms. You have lists. You have things that show up when you click other things. HTMX handles all of that.

On the other hand,

> I'm not a zealot. HTMX isn't for everything.

> Genuinely complex UI state (not "my form has validation" complex—actually complex)

But my interpretation is that any UI which displays the same data in just two places (like a "new notification" indicator as well as bolding new messages in an inbox, or a list of articles which can change dynamically as well as a count of the number of articles) is "complex" enough that you'll need client side state.

yawaramin 12/18/2025|

Nope, in that case all you need is an htmx out-of-band swap to update two different parts of the page.

delbronski 12/18/2025||

My main use of HTMX is to hack the Django Admin here and there. It works great for that. I’ve tried to use it in a moderately complex app and it became such a mess so quickly. I’m sticking with React for frontend stuff for now. Works well enough and I’m used to it now.

csomar 12/19/2025|

If you don't need React, you probably don't need a framework anyway. The reason I use React is to create components that can exist on their own (and can be constructed/visualized on a StoryBook) and these components will then play nice with other React components. And then use JSX to make reasoning about the code simple. That's not what htmx is.

> htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript.

From React website:

> React lets you build user interfaces out of individual pieces called components. Create your own React components like Thumbnail, LikeButton, and Video. Then combine them into entire screens, pages, and apps.

Apples and Oranges.

yawaramin 12/21/2025|

One would think so, except we are constantly seeing people creating React apps that should have been a few simple HTML files and some JS.

More comments...