undefined | Better HN

0 pointsleast1y ago0 comments

It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it.

But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables.

This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side.

I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.

0 comments

4 comments · 2 top-level

yawaramin1y ago· 2 in thread

> the payload size of fully rendered HTML is generally going to be substantially larger than JSON.

Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public.

Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.

leastOP1y ago

> No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them.

Are we talking about this in an absolute sense? because an html payload whether you compress it or not is generally going to be larger. It obviously depends on what your html looks like, but even if you only are using minimal class names and aria properties, it's still going to be larger than JSON in almost all cases. As in conservatively 50% larger but realistically even more than that, just based on admittedly rudimentary experiments. That's after minification/gzipping and tabulated data is best case scenario for HTML with the small element names (tr, td).

Does that actually matter? Maybe, maybe not. As you said, plenty of real world cases of JSON APIs that are sending excessive data or making calls to the server too much.

...but with things like HTMX, you're either hitting the server or you're using client-side processing of some sort (at which point we're back at why aren't we using something that effectively handles other frontend problems?). I also still think there's rather large downsides to having part of your frontend being handled by the responses from the backend, even if you're using only using full stack developers.

yawaramin1y ago

See for yourself: https://github.com/1cg/html-json-size-comparison

thunky1y ago

That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time.

Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html.

But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.

j / k navigate · click thread line to collapse