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.
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?
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.
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.