I don't do web stuff for a living, but I've been hacking since the early days of JavaScript - what I don't understand is what happened to separation of content, layout and interactivity - most of these react et al. monstrosities start with a big mess of JavaScript generating the html as lisp-like nested trees of tags. in that case, why not just use lisp?
2 neat libraries I've found to work like this are Surreal[1] and CSS-Scope-Inline[2] to get your Locality of Behavior (and Style) without a huge overhead.
That said, your markup can get unwieldy fairly quick, and you end up with a lot of similar and duplicated code/style blocks. My solution on a personal site, was to also use a backend-style templating library with partials[3], a file watcher[4] to build them automatically etc to kind of SSG a static site while maintaining reusable components. You can see where this is going, at what point does it make sense to just "reach for xyz framework" out of the gate? For as often as people (especially here) cry "ya aint gonna need it", there are at least as many times where people (less vocally) cry silently to themself, "I wish I'd just used a framework instead of unintentionally building a franken-framework".
This from a minimalist developer who has been doing it for a long time, with STRONG opinions about the modern state of the art. Honestly, it's very common for me to feel torn about ideals vs actual pragmatism.
The example there is kind of poor. The problem isn't that the implementation is separated (in fact the implementation of `hx-get` is just ignored, which is cheating). The problem is that the jQuery example is using a button id to specify behavior instead of an attribute like the htmx version. Old CSS wisdom was to give your elements meaningful classes and apply properties to those. Or xpath let you do pattern matching on elements/attributes and apply templates to that.
So the jquery version could be the same as the htmx one, but you do `$('[hx-get]').on("click"){...}` or whatever (I don't know jQuery/do javascript).
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself
of course you could do something in jquery like using a data attribute to store the url and HTTP method, etc, but at that point you'd be building https://intercoolerjs.org, the predecessor to htmx that was built on top of jquery
The htmx behavior is exactly as specified as the jQuery behavior, as what I'm suggesting is the last thing you said: you can literally implement the htmx attributes with jQuery.
That factoring has been the recommended way to separate concerns since before jQuery existed (e.g. with xhtml). Selecting specific IDs was always bad practice. Same with CSS. You were meant to use properties.
Tellingly, this is how html itself is designed. It's had ways to add your own tags since nearly the beginning, and the built-in ones stand as examples of how to design your custom tags' apis.
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself
of course you could do something in jquery like using a data attribute to store the url and HTTP method, etc, but at that point you'd be building https://intercoolerjs.org, the predecessor to htmx that was built on top of jquery
If you're being consistent, yes. The DTD specifies that you should refer elsewhere for the semantics, just as <button hx-get="/clicked"> has semantics that depend on whether you say "this is htmx" or "this is X library based on jQuery". Or alternatively those things all exactly specify the behavior, and you can go look at their specification for the details.
To the extent that it depends not on the code or its behavior, but on the interpreter that runs it, I suppose so. If you write the exact same code with the exact same meaning, I'm not sure why it matters.
I have never used a chocolate teapot, but anchor tags (and form tags) have been an important piece of the success of the World Wide Web as a hypermedia system.
htmx generalizes this notion of hypermedia controls in a syntactically symmetric manner, preserving the locality of behavior inherent in those controls.
it's not about the tag, it's about the claim that putting /clicked in the href or equivalent is somehow superior to $("#the-button"). click(function () { do stuff here}).
right exactly, it is superior in Locality of Behavior (LoB) terms because the behavior of the tag is apparent by only looking at it, whereas in the jquery example the behavior is in code that is located elsewhere.
It is also inferior in Separation of Concerns(SoC) terms.
These two design principles are in conflict and the reason I invented the term LoB was to help people, like myself, who prefer locality to argue for it effectively in software design discussions.
it's not like SPAs are more responsive today - they're horribly sluggish and things break constantly. modern and trendy doesn't mean better in any way.
