[guru4consulting]

My product has the typical SPA front-end and API backend. I understand that with HTMX, those API backends would have to return HTML fragments instead of JSON data (or another server endpoint that returns HTML fragments). I have few questions with this HTMX approach:

- We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B testing, quick iterations of UI/UX enhancements) without bothering about the backend. The backend API developers focus on API returning the right data and don't care about UI. I like this separation as it helps to really iterate the UI/UX faster. With HTMX, those backend devs will now have to worry about returning the correct HTML fragment based on the client device, position of the HTML div, etc. The presentation concerns spill over to backend developer and we are back to the days of server-side templates like JSP/ASP/RoR/PHP/Django. Anyone else sees issue with this approach?

- React/similar web apps can handle quite complex UI with multiple flows and navigations. I assume HTMX is probably not suited for complex UIs. Is that right? has anyone built any complex UI with HTMX?

[recursivedoubts]

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

[guru4consulting]

Thank you. Any idea on the impact of SEO for public facing websites using HTMX? Is it as simple as just rewriting URLs? React needs work arounds to overcome SEO issues.

[recursivedoubts]

If you use hx-boost (https://htmx.org/attributes/hx-boost/) for your nav, you shouldn't have issues w/ SEO.

You can get fancier for internal pages that aren't public facing, the search bar, etc.

Also consider the preload extension for faster nav:

https://htmx.org/extensions/preload/