yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity:
looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web
I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like.
One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with.
As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components.
HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end.
The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easily on the client side. That would affect the scalability and maintainability.
I'm not getting a sense of why HTMX would be better than a pure client/server approach. I have no attachment to "hypermedia," or any other concepts penned in the 1960s!
I don't know what you mean by reusable: you can reuse anything you create on the server side via various techniques (e.g. template inclusion, or using something like JSX for SSR, etc.)
A complex UI with nested structures covers a lot of area: the DOM is fundamentally a complex UI with nested structures. I'd need more specific examples to say anything intelligent about it.
htmx certainly doesn't necessitate round-trips for everything. HTML itself doesn't (see detail elements and HTML5 form validations) and client-side scripting is perfectly compatible with htmx:
htmx is better than a pure client/server approach in some cases because it relies on the already-built hypermedia client, the browser. This can, in some cases, dramatically simplify & improve applications:
(67% reduction in LoC, 96% reduction in dependencies, halved memory usage, 50% decrease in first load time)
Looking at your application, it appears to be amenable to the hypermedia approach, but I didn't do a deep dive on it. OTOH of course, if you are happy with the current approach I don't see any reason to move to hypermedia for its own sake.
https://htmx.org/essays/a-real-world-react-to-htmx-port/
looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web
I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like.
One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with.
[1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127