I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.

I‘d also like to know what you mean by tab sleep restoration.

answered here. https://news.ycombinator.com/item?id=39737557

Super balanced & informative writeup, thank you. Can you tell me what you mean by tab sleep restoration?

Last year chrome started discarding background tabs to save memory, probably should have said discard rather then sleep it's been a while since I worked on that. Our user base keeps tabs in background often in mobile devices and we saw some reports of it. https://arstechnica.com/gadgets/2023/02/chrome-110-will-auto...

When you do an htmx navigation to a new page, a discarded tab will "restore" only the last htmx fragment loaded, not the entire html page with style tags. Fix is to use unique url on push that isn't in local cache which forces a server reload on tab wake from discard.

Try adding the response header:

    Vary: HX-Request

Yep, probably browser caching:

https://htmx.org/docs/#caching

Next time I work on it, will try to see if that resolves it.

That worked for me. Thank you.

Htmx is what you want for making websites.

This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication.

So, if you are serving HTML, then htmx.

When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop).

(and in short amounts like creating complex widgets like maps, selects, etc).

---

I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side.

For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX.

Seems that HTMX requires unsafe-eval?

https://github.com/bigskysoftware/htmx/issues/2260

Nothing specific to React but having both client-side and server-side validation means that any deficiencies of server-side validation will be concealed and go unnoticed (until exploited by an attacker).

In contrast, server-side validation only means any validation deficiencies are more likely to be discovered during legitimate usage since the client-side validation is no longer covering up for it.

I think you have it backwards. You _first_ do server-side validation, then you add client-side validation _as an optimization_, so that invalid requests are not even sent.

My point is that once you do that any subsequent deficiencies in your server-side validation become invisible during normal usage (because the client-side validation will prevent you from even trying).

Actual hackers, the ones who try to hack your e-commerce site.

For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.

If you do server-side rendering of your React application, then it would be very similar to htmx from that perspective.

If it’s is purely a SPA, then all business logic would be behind secure APIs, so I don’t really understand your point.

That sounds like an irrational fear of front-end.

SPAs require implementing safety checks on both sides in 2 different languages. Many junior devs believe the client code is trustworthy and put important validation only in the client. I’ve worked with many codebases like this. If there’s only one place to specify validation, it should always be the server. So server side frameworks have this built in to their model and thus are less susceptible to this whole class of bugs.

> SPAs require implementing safety checks on both sides in 2 different languages.

This isn't exclusive to SPAs. For example, I am a .Net dev, and I have both front-end and back-end validation in most of my applications without ever using any SPA frameworks.

If I am in a pinch for time, I sometimes just drop front-end validation completely, and let the server handle the validation and then have the front-end handle the server validation responses accordingly.

>SPAs require implementing safety checks on both sides in 2 different languages.

Nodejs is quite popular. One language works on front-end and back-end. Like any language, security is up to the developers.

>Many junior devs believe the client code is trustworthy and put important validation only in the client.

Who is letting "junior devs" make these decisions? It sounds like they deserve to be hacked.

I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server

I'm using HTMX with Django for totem.org[0]. My over all experience is good.

I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast.

The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?).

Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller?

[0]: https://github.com/totem-technologies/totem-server

> The main downside I have with it though, is I just can't seem to remember how to use it

I've noticed the more I use HTMX, the more I tend to end up needing to use the JS API too.

For example, if I have an HTML table with inline editing, and I need there to be validation on what people are entering. So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logic e.g., if valid, then update table. If invalid, then display some kind of message or whatever.

HTMX has been working great for my needs, but the more I tend to get into the weeds of the JS API, I cannot help but sometimes question whether I am truly gaining that much more over using plain AJAX requests. However, HTMX is definitely more concise, so that's a nice benefit I suppose over a unmaintainable slew of AJAX requests.

> So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logic e.g., if valid, then update table. If invalid, then display some kind of message or whatever.

Couldn't that be handled server-side as well? I have my validation logic server-side, and it either returns the updated table row (or other element), or it returns the form again with validation/error messages, fields highlighted where the error occurred, etc.

> The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-swap, hx-swap-oob, hx-target?).

Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?

Maybe. I think it's just a high-level library for a specialized domain. It's not like imperatively coding JavaScript, spelling out each action step-by-step. The fact that I just need a little of it to do a lot means I just don't need to use it that much, and then I forget how.

I could see a better tutorial experience with live examples for common patterns. Something like SolidJS does (https://www.solidjs.com/tutorial/introduction_basics). That would be a good reference. Alternatively, a copy/paste pattern library, like what a lot of people are doing with Tailwind (https://daisyui.com/components/).

You might want to check out https://hypermedia.gallery

Disclosure: I built it (without HTMX).

This feels like the wrong way to look at things. It's not that it's "difficult" to switch from React/Vue to htmx - it's that it's easier to build with htmx in the first place. I wouldn't throw out completed code, but I'd seriously consider using it next time you start something new.

The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.

We use htmx (mostly via our django-livecomponents) on our production website, for several public facing features. We've initially replaced numerous small things that were built with Alpine before, and once we've gained confidence we rewrote our whole messaging app from reason/react app.

Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching.

Give htmx a try, it's worth a shot!

> django-livecomponents

Sounds cool. This one?

https://github.com/om-proptech/livecomponents

Yes :)

It depends on your options for managing state. If you can build a largely stateless UI, that can update from the server via a form submission or query parameters, then it’s a big win, both in terms of your code complexity and the complexity of the team you need to build it. You can still have lots of widgets on your page and even fancy CSS transitions to make it feel like an SPA if you really want. But if you’re making something very highly interactive or canvas based, with complex stateful UI components and gestures, then you probably have nothing to gain.

Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure.

All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.

It’s possible to build quite dynamic user interfaces with htmx - even games :-)

—> https://zakuchess.com/

One benefit I found to it is that it allows developers to keep the business logic entirely on the backed side, without having to duplicate any effort on the frontend side.

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

The problem was that on the whole people didn't use jQuery to "load html snippets" and the architecture of jQuery tended to push people towards client-side spaghetti.

htmx encourages you to put most of the logic on the server and to keep the client lean and clean.

But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.

Yes it's that, but more. I enjoy the out-of-bound swaps and triggering hx events or specific targets of render via response headers.

Yes, it's an implementation of the radical idea that we should deliver HTML (rather than a giant blob of JS) to clients purpose-built for rendering HTML.

See also https://hotwired.dev/

I help maintain a user-facing ASP.NET project running .NET Framework 4.5 that uses jQuery 1.0 for most of the UI. We launched our first new feature using HTMX back in November and it worked out pretty well for us and we plan to continue using it moving forward.

I also work on a React site and I wouldn't want to move away from it unless someone dared to utter the word rewrite.

I’ve been using HTMX on a greenfield project (not reimplementing something) and I’ve found it easy to work with and effective. Nothing magical, but simpler. Less effort, not more.

After being reminded of the importance of supporting low-spec clients[1] I’ve been testing without the HTMX library loading as well, and mostly that works like it should. I say mostly because I didn’t get the markup right everywhere yet.

I can see why some wouldn’t like it. But, it’s not a good/bad or works/doesn’t thing - it’s just different.

[1] https://danluu.com/slow-device/

Edit: typo, HTML -> HTMX

The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path.

There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment.

It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.

I don't know if HTMX is an alternative to React/Vue/etc, it always struck me as an alternative to a purely HTML site, which I think 95% of web apps should be. I don't know what we get from avoiding full page loads that we don't then lose when we make sites janky and taking ages to load.

Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).

I've mainly been a full stack dev for most of my career, though I do have a some experience in low-level domains. Lately, I have been mulling over if I want to jump into different field of development.

I know Rust is gaining traction, and I have always found languages like assembly, C/C++ to be more enjoyable than the higher level languages. So, I might try and take a stab at Rust and see where it can take me. I'm just so fatigued from all the web dev stuff. The whole field feels too scatter-brained to me.

Instead of trying to solve useful problems, I feel like much of web dev's frameworks are just focused solving an already solved problem with slightly differing and dogmatic opinions.

Well that is exactly right. These web frameworks, while they have their uses and have has some improvement on software engineering of web apps and have enabled sone benefits for users … largely the churn of these web frameworks with all these cute names are just reformulating the same technology over and over just with different opinions and aesthetics. People act like “technology changes all the time” but that’s not really what’s happening. We are “rediscovering” things so much in Web dev because we are still fundamentally doing, for the most part, what CGI programs did 30 years ago, pushing text back and forth with http verbs and return codes. Then, we make a huge deal when we get a web app to do something a desktop app could do 10-30+ years before.

I don't know if you've computed in 96, but computing now is orders of magnitude more frustrating than then.

Yeah … that’s why I put the “86” in the parenthetical but I think it’s worse then 1986 too. I worry about it getting more orders of magnitude worse!

For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere.

I totally get your sentiment.

By “sit on” do you mean “keep using” or “avoid”?

Keep using… Apologies for the lack of accuracy.