Hacker News Reader

Comment by ranger_danger | Hacker News Reader

The only big gripe I have about htmx is that the hx-on::after-request response it provides to your callback function does not automatically parse JSON content types like with e.g. jQuery.ajax(). Last time I brought that up, people simply questioned why I would ever want to do that in the first place.

View on HN

in 4.0 we are opening up the entire request/response/swap mechanism so you can replace any component of it per-trigger

you can replace the fetch() function used w/ an event callback, etc

should allow you to do pretty much anything w/o any hacks

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.

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.

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

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

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

> 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/

Reply on news.ycombinator.com