Before I begin to ramble; I don't see where your "just" comes from, in other words, where is the difference between our two statements?

> > it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.

> Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. > Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.

Sure, I agree with you!

What I don't like is the contrarian attitude of htmx team and the pretence of not using JavaScript. It's just progressive enhancement, a valuable and very old approach.

IMO, an approach best implemented without a "framework" like HTMX.

I mentioned Alpine, because I think in combination with blade "components" (which are just fancy template partials), I think it's better than HTMX (subjective opinion). Still, I'd advise against Alpine and for a simple external JS file for anything more serious than an MVP or a landing page.

Kudos to the htmx developers, who made a library out of their idea of progressive-enhancement JS.

My point is just that I don't like two things which seemingly repeat in each of their blog posts:

- They define their own language around REST and hypermedia to explain a string-language in HTML-attributes, which is then executed by JS. It's really not much different from Alpine. It's called "progressive enhancement" and a DSL in HTML attributes is not needed to implement it

- They start most posts about their library with a lengthy ramble about "cool kids and SPAs" vs "good old server-rendered HTML". This is a tiresome trope.

The first time I read their "HATEOAS / Rest is for humans" article, I found it witty. The second time I read an article explaining their appproach, I found it interesting.

By now, I just skip all the htmx stuff and jumped to the meat of the post, the new (JS!) API for page transitions.

I'm not really interested in learning a new "JS-in-HTML"-language.

TL;DR: Have you ever heard of frontend-fatigue-fatigue? :D

I wrote lots of vanilla JS which abused HTML attributes in similar ways.

For a simple landing page, I'll probably try htmx some day instead of writing this myself.

But I tend to not like this whole approach of "magic strings in HTML". When I do this in my own code, the point where an internal alarm rings is usually when HTML attributes start referencing comma-separated lists of unchecked... somethings (usually IDs).

Okay. I don't really care about the HTMX team attitude, the way they start their blog posts (that I don't read) or this funny concept of "frontend-fatigue-fatigue" so... what's left for me is a very useful tool for certain use cases that they kindly offer for free. But to each his own.

I know nothing about Alpine, will check it out.

Yes if htmx is the right tool for you, all power to you. I was not meaning to provide more than a tangential thought on their outward presentation.

an href is just a magic string in HTML :)

I'm old enough to remember the mess it was to force a file download at link clic. Now it's just a matter of using another HTML attribute. So yes, I like magic attributes. Actually, I wish something like HTMX was embedded in the browsers.

If it's well thought out, sure, why not. But the examples in the HTMX docs for me are mostly not as simple as common HTML attributes.

E.g. these are examples for what I meant by "DSL in HTML attributes":

    <input type="text" name="q"
        hx-get="/trigger_delay"
        hx-trigger="keyup changed delay:500ms"
        hx-target="#search-results"
        placeholder="Search..."
    >
    <div id="search-results"></div>

In the end, of course, standardized HTML has DSLs in attributes too (e.g. srcset, sizes...).

Using the word "magic" might have been a bit snarky, that's always a question of definition.

I meant that the behavior is neither standardized nor simple code that can be read as such. With Alpine it's the same, it's code in HTML attributes, but not all regular JS rules apply.

The first example for the transition from the release notes is another one:

    <div class="sample-transition">
       <h1>Initial Content</h1>
       <button hx-get="/new-content" 
               hx-swap="innerHTML transition:true"
               hx-target="closest div">
         Swap It!
       </button>
    </div>

Strings like "innerHTML transition:true" or "closest div" and the whole thing in combination are just not too much my taste, and I find that this is not really simpler than just writing JS.

But I can see how it fills a niche and I don't want to argue against this idea as such.

Just the presentation I can't understand.

HTMX is not an "extension of HTML" for my understanding, it's a JS lib that parses non-standard attributes using a DSL. Doesn't need to be bad.

Regarding the "download" attribute: I love it too, and I always love when I find out I can do something easily in HTML and CSS without using JS. Similar example, maybe not useful so often: the form attribute.

> E.g. these are examples for what I meant by "DSL in HTML attributes"

It's a DSL, sure, I won't argue about that. Matter of taste I guess, but I actually find this example you posted super easy to read, even the hx-trigger value. That's precisely what I like about HTMX: you get quite a lot done in a few attributes, while still remaining very readable. If the attributes value is too complicated or too long (ie. difficult to read), I would probably rewrite the logic in a simple JS function anyway.

> I always love when I find out I can do something easily in HTML and CSS without using JS

Ditto. When I wanted to play a media, it used to be some bad combination of flash object with JS bindings... now it's just a single audio and video tag. What a time to be alive...