Because it's a mish-mash of different ad-hoc DSLs.

You have a DSL based on data-* attributes

But then some attributes get this weird syntax-ish extension

Then some of those attributes accept a Datastar expressions DSL: https://data-star.dev/guide/datastar_expressions

So you can have

   data-on-click__debounce.200ms="$landingGearRetracted && @post('/launch')"

Which is just bad design

I can see what you're saying.

But again, the API design woes are subjective and I think it's perfectly fine to iterate on getting this to a nicer state.

"Wrong" to me suggests a gap in the understanding of fundamentals or of how things work. If the ideas of Datastar are fine to all of us, and our issues with it are ergnomics, then that can be a more focused discussion.

> But again, the API design woes are subjective

They aren't. This is not good API design

    <button data-on-click__window__debounce.500ms.leading="$foo = ''"></button>

> "Wrong" to me suggests a gap in the understanding of fundamentals or of how things work.

Snide vaguely dismissive remarks don't make such remarks true.

> If the ideas of Datastar are fine to all of us

Who's us? Are these "us" in the room with us right now?

We are limited to what is possible in the data dash-* spec. If you have better syntax that's going to work everywhere in every browser please let us know!

You literally have a custom Javascript-like DSL already https://data-star.dev/guide/datastar_expressions

This wilful insanity is completely incomprehensible to me (HTMX and lit are also fully infected with it): "Oh no, we are just HTML, we can't do anything" while literally doing tons of things outside of HTML.

What's your alternative that stay HTML spec compliant? Instead of whining show code

> What's your alternative that stay HTML spec compliant?

Again: you literally have a custom Javascript-like DSL in Datastar. Use that.

It's like the "it's just HTML" or "it's HTML-compliant" mantra somehow damages the brain, or something.

Edit: this custom JS-like DSL is so prominent and such a crucial part of Datastar, that it's referenced in the very first paragraph of reference: https://data-star.dev/reference

Oh, look, your HTML-spec-compliant thing in which it is apparently impossible to do anything outside data-* attributes somehow calls external functions, and updates signals, and reads signals, and does all sorts of things:

    <div data-signals-result>
        <input data-bind-foo 
           data-on-input="myfunction(el, $foo)"
           data-on-mycustomevent__window="$result = evt.detail.value"
        >
        <span data-text="$result"></span>
    </div>

But no! It's absolutely impossible to do something about data-on-click__window__debounce.500ms.leading

> They aren't. This is not good API design

Why isn't it a good API design?

> Snide vaguely dismissive remarks don't make such remarks true.

Agreed! I don't believe I was doing anything of the sort.

> Who's us?

People on this thread.

What design do you think would be better?

Both Datastar and HTMX have the same issue: they want to pretend to be HTML. So they force themselves into writing several DSLs like this to pretend that this is still "just HTML".

Since they have a full "Datastar expression" language, I'd just expand that. Then you wouldn't need these weird constructs:

   <button data-on-click__window__debounce.500ms.leading="$foo = ''"></button>

Datastar is spec compliant HTML. Please point me to the code that's not HTML spec compliant

Well they are both "just HTML", Datastar being better about being spec compliant using the dataset attributes and all.

By expanding the "Datastar expression" language, do you mean a compiled language or moving all the expressions into JS files or something else?

> By expanding the "Datastar expression" language, do you mean a compiled language or moving all the expressions into JS files or something else?

Doesn't matter. They literally already have a Javascript-like DSL: https://data-star.dev/guide/datastar_expressions