"I was late to the hypermedia party" → very late indeed :)

The term was coined in 1965 by Ted Nelson in: https://dl.acm.org/doi/10.1145/800197.806036

Here's the exact sentence: "The hyperfilm-- a browsable or vari-sequenced movie-- is only one of the possible hypermedia that require our attention."

Both Datastar and HTMX try to lay claim to being "the one true hypermedia" just because they both are vaguely HTML-like. And they gladly misappropriate Ted Nelson, too: https://dmitriid.com/hypermedia-is-a-property-of-the-client

in reality, neither of them make any such claims. And they are not html-like - they're literally html. Especially datastar, which doesnt add any non-html-spec attributes.

Yeah, yeah, they "literally add nothing" except these small things like "custom Javascript-like DSL" (datastar), custom DSL and custom HTTP-headers (htmx).

But it's "just html", so it's all fine

Edit: Oh, don't forget that " Especially datastar, which doesnt add any non-html-spec attributes" in reality ads two custom DSLs. One in the form of HTML attribbutes, and the other in the form of a JS-like DSL:

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

But as long as it's superficially HTML-spec compliant, this is nothing.

the spec is literally just data-* (hence the name): you can add whatever you want to it and remain in spec. And they're meant to be read by javascript (like datastar)

https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use...

At least you're living up to your profile! "Opinions on things I know nothing about"

> At least you're living up to your profile! "Opinions on things I know nothing about"

I've had this pinned on my twitter profile for a few years now, for people like you: https://x.com/dmitriid/status/1860589623321280995

I never argued that those attributes weren't compatible with HTML.

Hey, that was a low blow, you can do better than insult another user!

On the topic: it might be in spec but it’s still a DSL inside an attribute

Do you really not see how I was responding in-kind to them?

One frustration I have with OOB elements in HTMX:

1. If the element is out-of-band, it MUST have `htmx-swap-oob="true"` in it, or it may be discarded / cause unexpected results

2. If the element is not out-of-band, it MUST NOT have `htmx-swap-oob="true"` in it, or it may be ignored.

This makes it hard to use the same server-side HTML rendering code for for a component that may show up either OOB or not; you end up having to pass down "isOob" flags, which is ugly and annoying.

I think Datastar has the better approach here with making OOB the default. I suspect HTMX's non-OOB default makes more sense for very simple requirements where you simply replace the part of the DOM from which the action was triggered. But personally, situations where OOB is necessary is more typical.

Interestingly, elements sent via the HTMX websocket extension [1] do use OOB by default.

[1]: https://htmx.org/extensions/ws/

This really depends on your server-side HTML rendering approach. I have a library in which I can do this:

    node +@ Hx.swap_oob "true"

And this adds the `hx-swap-oob=true` attribute to the given node. It makes it trivial to add on any defined markup in an oob swap.

I get that many people prefer template-based rendering, but imho to extract the maximum power from htmx an HTML library that's embedded directly in your programming language is much more powerful.

https://github.com/yawaramin/dream-html/blob/f7928616b9ca1d6...

> to extract the maximum power from htmx an HTML library that's embedded directly in your programming language is much more powerful.

I'm actually using gomponents, but the maintainer doesn't like the vibe of adding attributes to existing nodes.

https://github.com/maragudk/gomponents/issues/276

(I don't really understand his argument, but in general I'm in favor of maintainers doing what they think is the right thing; and in any case I'm using his work without paying, so not gonna complain.)

But even if I had an easy way to add the attribute, the fact that I need to think about that extra step is a bit of extra friction HTMX imposes, which datastar doesn't.

I like the alpine-ajax API. You specify one or more targets and it swaps each of those elements. No default case or OOB, just keeping it uniform instead.

As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.

I thought alpine ajax did OOB on any ids returned in a response.

Edit: right, as long as the element has x-sync on it, it will receive any OOB updates from any response.

You can swap multiple elements with targeting too: `x-target="comments comments_count"`, but, yeah most of the time `x-sync` is better.