I would love more feedback from the accessibility engineering community so please look up my email or comment on the proposal if you think I've missed something.

[0] https://triptychproject.org/proposals/button-actions#what-ab...

This is correct. The point of the proposal is that you should be able to implement this pattern with just navigations, and that implementing it differently doesn't change the user semantics.

> If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two lines of progressive enhancement JavaScript to handle space.

One important stakeholder for the proposal is governments and other websites that care about building accessible web experiences that work without JavaScript enabled. There are also many differences in the behaviors that can't be rectified with JavaScript (some examples are in the original article as well as the linked proposal).

The proposal has an in-depth explanation of why this and other workarounds (like using the `form` attribute and a bunch of dangling forms) aren't sufficient.[0]

[0] https://triptychproject.org/proposals/button-actions#existin...

Also, that link has a lot of wrong information and is not an official W3C site. It even has a LinkedIn page.[0]

[0]https://www.linkedin.com/company/thewcagcom/

If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Patterns like this can be found all over the web on sites you certainly use.

> There's functionally no reason to do this. It doesn't add anything for the user, it only takes things away in the name of making it feel "more native".

There are many functional differences between buttons and links and it's not true that links are strictly more capable. Buttons, for instance, can be activated with the spacebar.

> I've been building websites for 25 years and I've literally never had this problem.

I included a link that showcases how this problem exists both in Django itself and for developers who build websites with Django.[0] This is representative of a durable, hypertext-driven, webapp design that the proposals are intended to support.

[0] https://www.djangoproject.com/weblog/2026/jul/15/supporting-...

Neither of my examples work with links. Logout buttons must be buttons because they trigger unsafe requests, and "search" buttons are buttons because they submit the form as a query parameter. Both of these examples, are, however, navigations.[0]

> Whether it looks like a button is irrelevant, that’s CSS.

It's not irrelevant, because even if you style a link like a button (or vice versa), it will still behave like the thing it actually is. That's why it's important to have native HTML behavior that lets people use the right semantic element.

[0] https://html.spec.whatwg.org/multipage/browsing-the-web.html...

Comments URL: https://news.ycombinator.com/item?id=49091738

Points: 67

# Comments: 51

That's to say nothing of all the syntax decisions you have to make now. If you want to do infix math notation, you're going to be making a lot of choices about operator precedence. The article is using a lot of simple functions to explain the domain, but we also have switch statements—how are those going to expressed? Ditto functions that don't have a common math notation, like stepwise multiply. All of these can be solved, but they also make your parser much more complicated and create a situation where you are likely to only have one implementation of it.

If you try to solve that by standardizing on prefix notations and parenthesis, well, now you have s-expressions (an option also discussed in the post).

That's what "cheap" means in this context: There's a library in every environment that can immediately parse it and mature tooling to query the document. Adding new ideas to your XML DSL does not at all increase the complexity of your parsing. That's really helpful on a small team! I agonized over the word "cheap" in the title and considered using something more obviously positive like "cost-effective" but I still think "cheap" is the right one. You're making a cost-cutting choice with the syntax, and that has expressiveness tradeoffs like OP notes, but it's a decision that is absolutely correct in many domains, especially one where you want people to be able to widely (and cheaply) build on the thing you're specifying.

And here's the datastar one, edited for parity: [1]

The htmx one is simpler. There's fewer mini-languages to learn and the API makes more assumptions about what you want. As you noted, Datastar has more generalized mechanisms that are certainly less clunky than htmx's if you lean heavily into more signals- or event-driven behavior, but for (what I believe to be) the majority use-case of a CRUD website, htmx's simpler interface is easier to implement and debug.(For example: you will see the response associated with the request in the browser network tab; I'm not sure if Datastar has a non-SSE mode to support that but it wouldn't be true for SSE.) To each their own.

As for "well then why implement X, Y, or Z," as the OP notes, refactoring to use fetch() means you get them largely for free, without compromising the nice interface. So why not?

[0] https://htmx.org/examples/click-to-edit/

[1] https://data-star.dev/examples/click_to_edit

]]>Tue, 04 Nov 2025 00:06:37 +0000https://news.ycombinator.com/item?id=45806038alexpetroshttps://news.ycombinator.com/item?id=45806038https://news.ycombinator.com/item?id=45806038Yes! I expect that I will mostly be sticking to `hx-target` though, for the reasons stated above.

My interest in htmx is more on the coarse-grained aspects of its interface, not the finer ones, which is a consistent theme in my writings about it [0].

[0] https://alexanderpetros.com/triptych/

]]>Mon, 03 Nov 2025 23:56:41 +0000https://news.ycombinator.com/item?id=45805960alexpetroshttps://news.ycombinator.com/item?id=45805960https://news.ycombinator.com/item?id=45805960> Why bother with v4 at all? If it dilutes that simpler interface?

v4 makes almost no changes to the interface, other than to flip inheritance to be off by default.

> I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?

Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`.

Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.

]]>Mon, 03 Nov 2025 23:16:36 +0000https://news.ycombinator.com/item?id=45805649alexpetroshttps://news.ycombinator.com/item?id=45805649https://news.ycombinator.com/item?id=45805649> why use HTMX when it really seems like (a heavier) Datastar-lite?

The reason to use htmx is that it has a simpler interface optimized for the majority use-case.

With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify.

Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission.

Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1].

[0] https://data-star.dev/essays/v1_and_beyond

[1] https://unplannedobsolescence.com/blog/less-htmx-is-more/

]]>Mon, 03 Nov 2025 22:18:32 +0000https://news.ycombinator.com/item?id=45805126alexpetroshttps://news.ycombinator.com/item?id=45805126https://news.ycombinator.com/item?id=45805126Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.

]]>Sat, 25 Oct 2025 05:36:31 +0000https://news.ycombinator.com/item?id=45701560alexpetroshttps://news.ycombinator.com/item?id=45701560https://news.ycombinator.com/item?id=45701560