3 ms·

> in exchange for having really small network requests after the load. I'd love to see examples of where this is actually the case and it's drastically differe

> in exchange for having really small network requests after the load. I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well. Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.

raron 1y ago
> I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://easyeda.com/ https://www.onshape.com https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?
- deleted 1y ago
  [deleted]
- niutech 1y ago
  No, HTTP compression is widely used (brotli increasingly).
- chuckadams 1y ago
  BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off. It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).
8n4vidtmkvmk 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.

raron 1y ago

> I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://easyeda.com/ https://www.onshape.com https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?

deleted 1y ago
[deleted]
niutech 1y ago
No, HTTP compression is widely used (brotli increasingly).
chuckadams 1y ago
BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off. It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).

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