[DrDroop]

What are you gonna do if you want to give a user the option to display the same search result in a html table and a map drawn on a canvas element, or maybe some info viz thing like a chart? No htmx fanboy has a nice solution for this. Im fine with making hyper media part of the synthesis but ignoring features that you have for free with modern hybrid ssr spa is not helping.

[jdpage]

I'm assuming that you're referring to the fact that if you get the data as JSON from the server side, you can use it to render out your multiple visualisations. If this is not what you're getting at, my apologies.

If you send the HTML table over the wire, you can use it as the datasource for the other visualisations, same as you would with JSON. You can extend it with `data-` attributes if necessary to get some extra machine-readable information in there, but I have not needed to do that yet.

On the application I'm currently working on, we do this and then have a listener on the htmx event to turn the table into a d3.js graph. It works pretty well, and has the advantage that if someone is using our application with JavaScript turned off, they still get the table with all the data.

[DrDroop]

Nice, what if I have a 3D model and I want to show extra info in a html div about a vertex, edge, face or object that I have selected?

[gsck]

This has nothing to with HTMX/Hypermedia, this is an issue with SSR. No pure SSR frameworks can do this.

You would do this the same way you would in any other website, have the server send the data required (Hypermedia or not) and use client side JavaScript to do the client side reactivity.

This is like asking why doesn't HTMX allow me to change the colour of a button when I hover over it, why should I have to do this on the client?

[bbg2401]

Then use a different tool which provides the precise capabilities you are needing? I'm confused by your hostility. HTMX doesn't have to solve every problem to be considered viable.

[DrDroop]

Boy you need to grow up quickly if you find this hostile already

[MisterTw22312]

This is doable, but for complex and component heavy UIs with much JS functionality and client-side-state HTMX is probably not the ideal choice. But for many other use-cases it is. It's good for probably 70% of the use-cases, the other 30% are for SPAs.

[recursivedoubts]

you would render the result as an HTML table and then as JSON, i would guess

https://htmx.org/essays/splitting-your-apis/

https://htmx.org/essays/mvc/

[biftek]

No one is stopping you from still having a JSON API if your hypothetical use case requires it.

The Accept header is there for a reason