Hacker News Reader

Comment by zamadatix | Hacker News Reader

I can tell it's Friday because it took until the section ID until I realized this was going to be about user comments on a website not  LOL.

If you've got Ruby listening for updates with a postgres database all tied into a content generator it's probably time to admit you don't have a static website anymore and just look for best practice ways to go about this (with a bit more security!).

View on HN

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.

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.

Same here... and I wouldn't call this a static page anymore if it runs JS on load, calls a HTTP endpoint which makes DB query which returns HTML that modifies the DOM.

but if you can host your site from an S3 bucket, would it not be called static? to me, static means no server side languages necessary to render the page. if your statically served JS can call a remote host to pull down some data that updates things client side, it's still considered static, from a hosting perspective.

Wouldn’t that definition would apply to standard SPAs as well?

I guess it depends on perspective. What a host service that will charge you more money for a non-static site, a client-side JS app can still be considered static.

We might also be blurring lines of static sites vs interactive sites. You can have a static site that does nothing but allows the user to scroll to view it. You can also have static sites that change and do things based on the user's input. Entire games have been made using client-side JS but is still served statically.

IMO if a web user triggered event triggers a server side page regeneration they see when the page reloads what you have is more a dynamic site with caching not a static site. "It's a write-to-file-before-serving site" isn't really a meaningful distinguisher but "the site functions the same when you only have a copy of the website files" is.

The JS doesn’t trigger a DB query, it loads a static comments file previously generated by Ruby at the time the last comment was inserted or modified. It could be replaced by a server-side include.

Yep, it's not static because data in the DB is changing the file.

It's saturday here now, I've slept plenty and I still interpreted the headline the same way. But the topic is plenty interesting too, I'm curious how far the SSG movement will take it.

Reply on news.ycombinator.com