| If the FE/BE split is working well for you, then htmx isn't as compelling. It is more compelling when you have full-stack developers who can take ownership of entire features and shepherd them from start to finish, without needing to coordinate with another team to get the data/functionality they need. Here is an example of a fairly sophisticated application that was written in react, then moved to htmx with good results: https://htmx.org/essays/a-real-world-react-to-htmx-port/ As far as what you can achieve with htmx, I outline when hypermedia (the more general concept behind htmx) is a good choice or a bad choice here: https://htmx.org/essays/when-to-use-hypermedia/ You can get an idea of the basic level of interactivity you can achieve with htmx by looking at the examples: https://htmx.org/examples/ all of which compose well together. You can get more dynamic than that if you are willing to do client-side scripting (https://htmx.org/essays/hypermedia-friendly-scripting/) another essay that might be of interest, regarding your APIs: https://htmx.org/essays/splitting-your-apis/ and, if you want a complete introduction and overview of the hypermedia approach, we have a book available online for free: https://hypermedia.systems |