That sounds like use-case exploration? Did you answer?

One of the actual responses was "Htmx isn’t designed to work with JSON APIs at all. It needs HTML back from the server."

It sounds like they are referring to hx-swap and not arbitrary javascript callbacks though, and in that case, I don't see why calling JSON.parse() inside htmx (when the content-type is json) is that big of a deal.

▲

isleyaardvark 3 days ago | parent | next [-]

It's a pretty core part of their design philosophy, possible the core.

https://htmx.org/essays/rest-explained/

	▲	sudodevnull 2 days ago \| parent [-]
		So you can support JSON while still being REST. For example, Datastar supports merging in HTML, JS, JSON into the current view of a resource. They work together to keep the resource state unified versus polling. In general the Datastar way is... 1. make an MPA 2. each page is a resource 3. keep a stream open on the current state of that resource 4. ship, touch grass, repeat

▲

johannes1234321 3 days ago | parent | prev | next [-]

They don't want to become a general purpose dynamic web library, but focus on swapping server generated HTML blocks. It's a conscious decision in what they are and what not.

▲

bananapub 3 days ago | parent | prev [-]

> One of the actual responses was "Htmx isn’t designed to work with JSON APIs at all. It needs HTML back from the server."

Uh, yes? They wrote a literal book about why they think this is important: https://hypermedia.systems/