6 ms·

I tried to use htmx but the client side templates extension (allowing you to transform json into html client side using a template) doesn't support json arrays.

I tried to use htmx but the client side templates extension (allowing you to transform json into html client side using a template) doesn't support json arrays. Maybe I don't understand the right way of doing things with htmx, but returning large amounts of html seemed like it's a waste of bandwidth to me. That said, I appreciate htmx not having a build step. Even tailwind gets annoying to me.

nisegami 3y ago
It's not surprising that HTMX didn't allow you to do that because that's pretty explicitly not what it wants to be. HTMX is all about sending HTML over the wire, not JSON. If your HTML/JSON is gzipped, it shouldn't be significantly different in terms of bandwidth. Plus, you're not bundling nearly as much javascript with your site compared to a heavy client side framework, not to mention savings from avoiding processing more than just the DOM update on the client.
loloquwowndueo 3y ago
Returning partial HTML from endpoints is the whole point of htmx. If your endpoint returns json and you’re trying to convert that to HTML to use with htmx, don’t bother - just use another “traditional” Js framework. I highly recommend the “building hypermedia systems” book (free at https://hypermedia.systems/ https://hypermedia.systems/) so you can understand the HTML/ hypermedia architecture of which htmx is a key component and how it’s meant to be used.
- yellow_lead 3y ago
  Thanks, will take a look at the book. Your points make sense, but having an extension dedicated to this made me think returning JSON may be ok.
  - loloquwowndueo 3y ago
    If you have an endpoint that returns json and you can’t change for legacy, historical, compliance reasons, it might make some sense to integrate with an application that uses htmx the way it was intended and only needs that one weird legacy endpoint returning json to be converted to HTML client side. That sounds like the use case for that extension - the other explanation is someone wanting to jump on the htmx bandwagon without understanding the philosophy, and so trying to keep returning json, converting to HTML on the client and then trying to shoehorn this into a hypermedia architecture :)
- perilunar 3y ago
  > just use another “traditional” Js framework Or don't use a framework at all. It's easy enough to convert JSON to HTML — you only need a few lines of JS.
googlryas 3y ago
Almost all http clients send Accept-Encoding headers that will significantly shrink the response. Try just gzipping an example html response to get an idea of how good it will be.
- yellow_lead 3y ago
  Makes sense, thanks.
dpe82 3y ago
You may be surprised how well HTML compresses.
rakoo 3y ago
> large amounts of html It only sends large amounts of html if there is a lot of data, and if there is a lot of data it will send large amounts of JSON. html in itself doesn't add much, it's the data that makes the bulk of the content

nisegami 3y ago

It's not surprising that HTMX didn't allow you to do that because that's pretty explicitly not what it wants to be. HTMX is all about sending HTML over the wire, not JSON. If your HTML/JSON is gzipped, it shouldn't be significantly different in terms of bandwidth. Plus, you're not bundling nearly as much javascript with your site compared to a heavy client side framework, not to mention savings from avoiding processing more than just the DOM update on the client.

loloquwowndueo 3y ago

Returning partial HTML from endpoints is the whole point of htmx. If your endpoint returns json and you’re trying to convert that to HTML to use with htmx, don’t bother - just use another “traditional” Js framework. I highly recommend the “building hypermedia systems” book (free at https://hypermedia.systems/ https://hypermedia.systems/) so you can understand the HTML/ hypermedia architecture of which htmx is a key component and how it’s meant to be used.

yellow_lead 3y ago
Thanks, will take a look at the book. Your points make sense, but having an extension dedicated to this made me think returning JSON may be ok.
- loloquwowndueo 3y ago
  If you have an endpoint that returns json and you can’t change for legacy, historical, compliance reasons, it might make some sense to integrate with an application that uses htmx the way it was intended and only needs that one weird legacy endpoint returning json to be converted to HTML client side. That sounds like the use case for that extension - the other explanation is someone wanting to jump on the htmx bandwagon without understanding the philosophy, and so trying to keep returning json, converting to HTML on the client and then trying to shoehorn this into a hypermedia architecture :)
perilunar 3y ago
> just use another “traditional” Js framework Or don't use a framework at all. It's easy enough to convert JSON to HTML — you only need a few lines of JS.

googlryas 3y ago

Almost all http clients send Accept-Encoding headers that will significantly shrink the response. Try just gzipping an example html response to get an idea of how good it will be.

yellow_lead 3y ago
Makes sense, thanks.

dpe82 3y ago

You may be surprised how well HTML compresses.

rakoo 3y ago

> large amounts of html It only sends large amounts of html if there is a lot of data, and if there is a lot of data it will send large amounts of JSON. html in itself doesn't add much, it's the data that makes the bulk of the content