I just don't get what you're chasing after. All this seems more complex (to develop, to maintain, to operate, to manage) than what I'm doing with (P)React (Native) and APIs.
And where are the thousands of pre-made components like React has?
- no reduction in app ux
- code base reduced by 67% (21,500 LOC to 7200 LOC)
- total JS dependencies reduced by by 96% (255 to 9)
- web build time reduced by 88% (40 seconds to 5)
- Time-to-interactive reduced by 50-60%
- htmx allowed them to display much larger data sets
- memory usage reduced by 46% (75MB to 45MB)
the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)
i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think
there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation
