Htmx is part of the GitHub Accelerator

What am I missing?

I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content?

The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.

For instance, inside an HTMX application, I just coded up a plain ordinary (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in

https://hyperscript.org/

Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.

If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.

Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.

I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.

React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.

Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP

https://en.wikipedia.org/wiki/Wireless_Application_Protocol

which had a way to send multipart forms to the client. Something like that designed to work with a software factory

https://www.amazon.com/Software-Factories-Assembling-Applica...

(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)

or a "no-code" app builder could be great.

I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.