Hacker News Reader

Comment by layer8 | Hacker News Reader

I’d regenerate the complete HTML page server-side whenever a comment changes, instead of only regenerating the comments section, to obviate the secondary loading via JS.

View on HN

There is some advantage in splitting it in that the page itself stays cached even as the comments change and the page doesn't need to wait for the comments to be transferred to start rendering. You could keep this advantage with <iframe> if you really wanted to avoid JS though. It's a shame html imports died, they were a bit more lightweight.

Which advantage is that?

Cached pages load faster?

If you're just slinging static HTML, there's really not that big of a difference, and if it's a frequently accessed resource where a difference might be expected to matter, it will be cached regardless.

Hilariously enough, that's no longer true in many parts of the world; according to firefox telemetry, on-device storage is frequently much slower than the network.

Do you happen to have a link for that? It seems pretty counterintuitive given the state of modern PC hardware.

https://bugzilla.mozilla.org/show_bug.cgi?id=1392841 is the bugzilla bug to enable the feature by default.

https://simonhearne.com/2020/network-faster-than-cache/ has some discussion.

> the page doesn't need to wait for the comments to be transferred to start rendering.

It doesn't. Browsers will happily render half an HTML page as it's streamed in. There's an interesting HTTP 203 on this. https://web.dev/shows/http-203/LLRig4s1_yA/ if you're interested.

Interesting, will have to give that a listen. Thanks!

Server side includes work nicely for this, I think nginx was what I used (long time ago now). You can even inline them on load but reload htmx-style with minimal effort.

Reply on news.ycombinator.com