Please just try HTMX - Hacker News

Posted by iNic 6 days ago

Please just try HTMX(pleasejusttryhtmx.com)

614 points | 502 commentspage 4

nicole_express 6 days ago|

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 5 days ago|

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

mythz 6 days ago||

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 6 days ago||

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

CompuHacker 6 days ago||

The link doesn't point to an HTTPS server.

philipwhiuk 6 days ago||

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

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

DaSHacka 6 days ago||

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

g947o 6 days ago|||

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

DaSHacka 5 days ago||

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 5 days ago||

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 5 days ago|||

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

g947o 3 days ago||

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 2 days ago||

Which browsers are not doing this?!

aembleton 5 days ago||

> 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 5 days ago||

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 5 days ago||

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 2 days ago||

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 5 days ago||

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 5 days ago||

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 2 days ago||

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.

codedokode 5 days ago||

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.

politelemon 6 days ago||

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

mattlondon 5 days ago|

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)

mvdtnz 5 days ago||

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 5 days ago|

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

csomar 5 days ago||

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 2 days ago|

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.

moggers123 4 days ago||

What's the grug brain method of "live updating list with a search bar". I tried htmx sse but it turned out to be not that great. I was hoping I could model it as a single request/response cycle like a traditional page post, with the astericks that the single response is actually a stream of responses. Clicking search or whatever again "just" axes the old request and sends another one with the updated parameters. Perhaps the form being dirty would actually be what axes the stream.

yawaramin 2 days ago|

https://htmx.org/examples/active-search/

kgeist 5 days ago|

I've used HTMX on a personal project of mine. Other than HTMX itself, it used Go templates + Tailwind for CSS. As a backend dev with almost no professional frontend experience, I was able to replicate a fairly large and feature rich React app (which I was inspired by) using htmx in a matter of weeks in free time.

The main problem for me was storing/passing state between too many fragments. At some point some pages can become too complex to be manageable by HTMX, unfortunately. Lots of little fragments depending on each other, I began struggling to maintain a clear mental map of what was going on.

I'd say if React is more like functional programming, HTMX sometimes feels like GOTO programming.

More comments...