[philipswood]

The philosophy of HTMX is not to send JSON, but HTML fragments.

[majorchord]

They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.

[purerandomness]

Then what's the point of using HTMX?

If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.

The whole idea of HTMX is to get rid of the extra steps.

[majorchord]

I don't always have control over the remote end or due to business reasons the format can't be changed.

And since htmx also has template plugins, being able to feed JSON values into it makes sense to me... a similar project, EHTML has this feature.

[yawaramin]

You would use htmx when you control your backend server. Otherwise, you would use something else.

[ncruces]

But why?

[majorchord]

Fetching data from APIs I have no control over, or ones that serve multiple purposes and use a single response format

[ncruces]

HTMX uses HTML snippets over the wire to replace HTML elements on the client. It's not supposed to grow to support every use case you can imagine.

If you're calling APIs that you have no control over, you do so on your server.

That's the entire point of HTMX: the minimal necessary addition to browsers/HTML to allow HTML REST APIs to update pages without full page loads.

[philipswood]

Personally, I wouldn't consider HTMX to be a good fit for those scenarios.

Obviously you _could_, and it might even work well, but I think that's using the tool against its grain.

[kemayo]

I guess I could see it for decoupling your need to control the API you're using. The case where you have an existing API, whether your own or someone else's, and just want to get a new frontend hooked up to it.

[purerandomness]

Just put any template rendering engine in-between.

Htmx is "bring your own backend", but you do have to have a backend, be it Haskell or Zig or Gleam, that talks to your API, and renders HTML.