Totally agree with the stance, but it's pie in the sky stuff when it comes to real world, often imperfect, codebases.
Take for instance a piece of code I was reviewing earlier today. A class in one package referenced a function in a database manager class, which itself referenced a function in a DAO, which in turn contained some SQL. Just to figure out what was going on I had to read, parse and follow through on each. And this is the recommended design pattern too!
Exactly this! I like the concept a lot but perhaps an event handler being declared in-line in the component template isn't the best example of when this concept becomes really useful?
Event handlers in the HTML template look great for toy examples like <button hx-get="/clicked">Click Me</button>.
Personally, I think any reference to code within the HTML is bad - especially anything referencing code like the “clicked” identifier. It starts to look like line noise when there are many event handlers, and also I prefer my HTML to be as pure as possible (which makes validation and editing easy). Instead code and events within the component JavaScript/TypeScript should reference named nodes within the HTML template - nodes named by purpose.
I wrote a frontend framework doing this, and it worked really freaking well and components were a pleasure to code. The template didn’t need any tricky parsing, instead it was just boring HTML. Never mixing HTML and strings avoided most XSS opportunities. Most of the DOM is inherently secure.
The idea of HTMX is to mostly eliminate JS, and move everything into either HTML or the server. It's kind of like old fashioned <form>s, but for all elements and for more dynamic pages.
This allows the frontend to be simpler, while the backend is ironically also less complex because the only special feature you need is support for sending partial HTML (fragments). This as opposed to needing to embed your entire frontend framework in your backend to allow your website to load in a reasonable time, run in browsers with JS disabled, be easier to crawl, etc.
That said, do you have a link to your frontend framework? I always enjoy seeing different approaches to the same or similar problems.
Take for instance a piece of code I was reviewing earlier today. A class in one package referenced a function in a database manager class, which itself referenced a function in a DAO, which in turn contained some SQL. Just to figure out what was going on I had to read, parse and follow through on each. And this is the recommended design pattern too!