4 ms·

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

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

least 2y 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.
- yawaramin 2y ago
  See for yourself: https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison

least 2y 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.

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