Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g.

Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g. just the partial of the "Todo" list in your "Todo App" homepage). You need some backend logic to handle that but still much less than a full blown JSON API would have. They also have extensions that can diff and merge the DOM so even a full page load would replace just what changed, this way your backend is pretty much unaffected (you just end up serving more MBs). There are other libs in this space by the way, like Unpoly and Hotwire, HTMX just got more mindshare. > Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems I absolutely agree. I had a comment thread with HTMX's creator about this, I feel like it's a bad idea to shove logic into that. He also created Hyperscript (https://hyperscript.org https://hyperscript.org) so it's something he doesn't think is an issue. In general I think it's pretty easy to rein that in. Just use HTMX to do most of the plumbing it's strong at (react, fetch, swap) and keep the logic server-side. In my experience that covers the vast majority of web apps. If I absolutely need more client-side logic I'd reach for a little JS code or create a Web Component.