Hacker News new | ask | show | jobs
by troupo 258 days ago
> 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?

2 comments

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.