I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
In the end what you get out of your React code after your build process is vanilla HTML, CSS and JS. While you might be able to abstract some of those things away using libraries, all you‘re doing in your React code is building and manipulating HTML DOM trees within your React code and styling them using CSS (or using some abstraction like CSS-in-JS, CSS modules, etc.). To do so efficiently, you not only require knowledge of how exactly HTML and CSS work but also what React tends to do under the hood to render out your application. Even more so when things like a11y are required. A good dev also knows when to use JS to reimplement certain interactions (hover states, form submits, etc.) and when to use the native functionality instead (for example CSS pseudo selectors or HTML form elements).
All this is to say that I disagree with the notion that React devs don’t know or understand the underlying technologies. It might be different and more abstracted, but it’s still the same technologies that require the same or more understanding to be used efficiently.
If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application. That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring. When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements.
On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.
No, not like Gmail. Orders of magnitude less complex than that.
No, being JS/React "native" wasn't the problem there. Actually the opposite. The developers were not willing to think about an application with state, and when they found modelling this hard (with Redux), they decided that React (a different technology) was the problem.
You need to be catastrophically bad to mess something like htmx.
If you are doing things like eCommerce, form heavy, read heavy, websites (the majority) instead of full apps like a paint/game/code editor (that I say should start with htmx and small components with whatever), htmx IS so simple.
What kind of messy backend this projects have that failed it? Because this is the point: htmx is just html with a bit of more interactivity.
To fail with htmx then you MUST has failed to render html well, and if that is the case, with react will be even worst.
An outcome like this suggest that if the project were made in react or similar it will have failed even harder