(no title)
drbawb | 2 years ago
HTML is not the host programming language: that'd be JavaScript. Arguably, in this case, it's also whatever is on the other side of the HTTP requests htmx is making; which is almost certainly _not_ HTML.
htmx is maintaining its own event-loop (to react to DOM changes, read attributes, auto-wire itself, etc.), it's _calling into_ the user's code, either via the _declaratively configured_ HTTP endpoints when reacting to DOM events, or via callbacks provided by your event subscribers. These reactions were not explicitly programmed by a library-user in JavaScript, the host language. They were configured in markup and your framework altered its internal state and event-processing accordingly based on that configuration.
It is very much magic, and very much behaves like a framework. (I say this with the utmost respect, I don't think "framework" is a dirty word or anything. htmx is great conceptually, you've done a fantastic job implementing it, and it's a blast to use. I don't think it being a "framework", per this definition, detracts from what it is. I think it can also compete with other frameworks _just fine_ without needing to twist semantics.)
htmx's model is no different to me, conceptually, than Phoenix, Rails, et al. "magically" knowing which controller & action to invoke because I declared a route somewhere in a DSL, which they in-turn invoke to respond to an event. (I definitely don't consider either of those to be libraries.) What sets htmx apart is that it's a small, focused, _easily understood_ framework.
I do understand the need to differentiate htmx from the contemporary burdensomely-complex JS frameworks, but I don't think framework v. library is the right way to frame it.
recursivedoubts|2 years ago