Hacker News Reader

Comment by wild_egg | Hacker News Reader

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

View on HN

> 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://www.onshape.com

> because HTML compresses incredibly well

Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?

No, HTTP compression is widely used (brotli increasingly).

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

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.

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

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.

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/

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?

Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though.

Use JS to patch over things the browser doesn't implement and let it handle the rest.

Ok, at least we agree on something. I think that's fine if your app is simple enough, but the more and more dynamic it gets, at a certain point, I think it makes sense to just render the whole darn thing in JS. At least for the DX.

> The idea is that you never have to send the template again after that.

This implies or assumes that sending the template again is a problem. In practice, it's not. HTML compresses well and the difference between the compressed JSON and HTML response is often on the order of hundreds of bytes. That assumes equivalent data content which, as I've said above, is often not the case. JSON payloads tend to be larger and we need more of them to render the same UI.

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

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.

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.

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.

No, but doing the rendering through JavaScript in userland will be slower than letting the browser handle it

Reply on news.ycombinator.com