Hacker News Reader

Comment by yellow_lead | Hacker News Reader

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.

View on HN

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/) so you can understand the HTML/ hypermedia architecture of which htmx is a key component and how it’s meant to be used.

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.

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 :)

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

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.

You may be surprised how well HTML compresses.

> 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

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.

Makes sense, thanks.

Reply on news.ycombinator.com