HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler applications.
If I request a page, how does it know to only serve / fetch / render the main content vs the full page?
---
It seems like a lot of would be logic a real language has been moved to DSL and strings, i.e.
https://htmx.org/docs/#swap-options
`hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'"`
Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems
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) 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.