3 ms·

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, bu

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

maccard 1y ago
HTML templates are still text, text compressed well. As with all these discussions “it depends, profile it” is the only answer. People blindly assuming that X is better is why things are slow and shitty in the first place
goatlover 1y ago
Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.
- 8n4vidtmkvmk 1y ago
  They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.
  - wild_egg 1y ago
    Why on earth would you do a full page refresh on every interaction? Browsers have native support for partial page updates and prefetching. JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.
- hasanhaja 1y ago
  No, but doing the rendering through JavaScript in userland will be slower than letting the browser handle it
wild_egg 1y ago
> I don't have stats to back that up. Your comment then falls under my "superstition" label. My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything. You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.
- 8n4vidtmkvmk 1y ago
  For first load, yes. The idea is that you never have to send the template again after that. Cascading is a separate problem. You can bundle all the data into a single request if you want. You can even send JSON along with the HTML in the first request.
  - hasanhaja 1y ago
    Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server? For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/ https://htmx.org/examples/lazy-load/
    - 8n4vidtmkvmk 1y ago
      If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?
      - wild_egg 1y ago

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

maccard 1y ago

HTML templates are still text, text compressed well. As with all these discussions “it depends, profile it” is the only answer. People blindly assuming that X is better is why things are slow and shitty in the first place

goatlover 1y ago

Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.

8n4vidtmkvmk 1y ago
They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.
- wild_egg 1y ago
  Why on earth would you do a full page refresh on every interaction? Browsers have native support for partial page updates and prefetching. JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.
hasanhaja 1y ago
No, but doing the rendering through JavaScript in userland will be slower than letting the browser handle it

wild_egg 1y ago

> I don't have stats to back that up. Your comment then falls under my "superstition" label. My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything. You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.

8n4vidtmkvmk 1y ago
For first load, yes. The idea is that you never have to send the template again after that. Cascading is a separate problem. You can bundle all the data into a single request if you want. You can even send JSON along with the HTML in the first request.
- hasanhaja 1y ago
  Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server? For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/ https://htmx.org/examples/lazy-load/
  - 8n4vidtmkvmk 1y ago
    If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?
    - wild_egg 1y ago