I was able to find architectural patters that work smooth as glass.

Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error code) - No fragment orchestration: Not returning 3-5 fragments; using hx-swap-oob sparingly

Here is how I update fonts on screen in user prefs: User selects font → JS updates body class immediately → htmx.ajax() saves in background → done

vs. the anti-pattern you're describing:

User submits form → backend validates → returns success fragment OR error fragment OR partial update OR redirect signal → frontend must handle all cases

No language or programming paradigm is perfect. All programming is an exercise in tradeoffs. The mark of a good CTO or architect is that ability to draw out the best of the technology selection and minimize the tradeoffs.

> Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.

Well, frontend and backend always need to agree on every scenario, that's why I prefer to do validation on backedn and frontend to just display it and not do any validation.

I found the book (hyper media systems) to be better at explaining full integration than the library site, which gives nuts and bolts and big picture, but not much intermediate info.

Real world examples with error handling would be great for HTMX. Now in the LLM era you might get away without those. I just don't understand why can't we have complete documentation for the most basic scenarios.

> and is great for agentic AI coding.

Definitely sad to see this everywhere nowadays, tech choices made because of AI

> Frontend and backend must agree on every scenario

When is this not the case?

Just to be completely clear... you do not need React just so you can turn JSON into HTML. HTMX can 100% can do that.

You're argument is fine assuming you wish to become another react frontend in a sea of react frontends.

But the documentation example is a terrible argument, the benefit of HTMX is it is easy to understand what is actually happening. There is no magic, you don't need to dive through millions of lines of code to figure out what this is doing like react. It's very basic javascript. Just read the library, frankly you don't even need any documentation. Just take 15 mins and read the entire library.

So first you choose a nicher solution you didn't fully understand and now you jump into another one (full of issues but popular) you likely don't understand the trade offs too?

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere..

Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full React fancy component lib SPA that is eventually just compiled down to a zip bundle of files that the backend needs to know nothing about and can serve as dumb files. The backend is a JSON API of sorts that I would need to build anyway for other use cases.

> Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.

And why would that differ from React?

When I was building a website with React, I needed to model a "apply coupon" endpoint with different states (coupon applied, coupon does not exist, coupon exists but has reached its max usage limit) and it was so annoying because you needed to

1. The backend route that returns JSON with a different model depending on the coupon state

2. The JSON models for each response type

3. And then on the frontend you need to load the data, parse the JSON, figure out which "response state" it is (http status code? having a "type" field on the JSON?) convert the JSON to HTML and then display it to the user

In my experience it added a lot of extra "mental overhead". It is something that should be extremely simple that ends up being unnecessarily complex, especially when you need to do that for any new feature you want to add.

When using htmx, a simple implementation of that would be

1. A backend route that returns HTML depending on the coupon state

2. Some htmx attributes (hx-post, hx-swap) on the frontend to make the magic happen

Don't get me wrong, there are places that you wouldn't want to use htmx (heavily interactive components) but that's why htmx recommends the "islands of interactivity" pattern. This way you can make the boring things that would add unnecessary complexity when using React with htmx, and then you can spend the unused "mental overhead" with the interactive components. (which, IMO, makes it a more enjoyable experience)

At the end of the day it is just choices: Some people may prefer the React approach, some people may prefer the htmx approach. All of them have their own upsides and downsides and there isn't a real answer to which is better.

But for my use case, htmx (truth to be told: I use my own custom library that's heavily inspired by htmx on my website, but everything that I did could be done with htmx + some htmx extensions) worked wonderfully for me, and I don't plan on "ripping it all out" anytime soon.