Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request.
I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.
I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything.
That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.
SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive.
I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.
This is not SSR.
If you do SSR, the client is much more limited in terms of caching because the page contents is not constant. In my opinion, SSR is actually more for slow CPUs than for slow networks since you can make the network usage for client side rendering very efficient as well, but client side rendering will always be worse in terms of client CPU.
In the context of the comment to which you're replying[0] I'm not sure how else to take your comment. OK, you don't like HN's UX, that's either a comment on SSR and on topic for the thread, or completely unrelated.
> HN as a site is a perfect example of how bad a SSR experience can be.
This is a great ending line if the things you list before it would automatically be better under CSR, or are only capable of being fixed by moving HN to CSR. So, it seems pretty natural to me to assume that you're saying those things (reply notifications, typography, losing position on a reply) would be better under CSR, which is not necessarily the case.
function vote (id, how, auth, _goto) {
...
$('unv_' + id).innerHTML = unv;
new Image().src = vurl(id, how, auth, _goto);
}For me this is 45ms to transfer the 2 kB (compressed) of HTML; the whole process takes under 60ms total, which is pretty darn close to "instantaneous" for the "complete page reload."
EDIT: I'm in Texas, so most of this time is probably just round trip time to the west coast.
It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.
No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cache instead of generating a page for you.
A cache is not a static site, although maybe next.js is redefining the term, I don't know. Get off my lawn.
What I actually mean is, that there is a difference between SSR with react, which requires some kind of rehydration on the client, in contrast to a website generated by, e.g., PHP on the server, which doesn't require this.
The PHP website doesn't require the client to rehydrate and produces less load on the client. With the disadvantage, that a subsequent page view requires again a full load, while the SSR loaded react page, doesn't require that.
I didn't check the HN code yet, but it feels like a server- side generated website and not a SSR delivered react (or similar js framework) website...
Here's a simple way to think about it.
SSG: there will be a process that generates/bundles HTML/CSS/JS ahead of time with all of the content that the site will have, like the many static site generators out there.
You should then be able to take the output of the SSG process and host it on a dumb web server, like Apache/Nginx.
For example, that's what I do with my HN Personal Blogs site, a set of Python scripts generate HTML output a few times per day, which is then served on an Apache container: https://hn-blogs.kronis.dev/
SSR: there will be a runtime of some sort that will execute any number of scripts on the server, to dynamically generate a response for the user's request.
This is what many PHP and Ruby sites are, if they don't opt to just use those languages for an API. You click on a button in the site, your request is submitted, the language runs some logic on the server and sends you a response, typically there's a DB as well, that most users interact with.
However, you can also mix those approaches. For example, you could make it so that the front page of your site is pre-rendered or at least cached, so that your servers need to do less processing and your DB would be under less load.
That's also what some flat file CMSes like Grav do - so that the articles will load pretty quickly, though those approaches introduce some complexity and the risk of stale data in some cases.
There's also stuff like hydration and many more recent concepts, but that'd get more lengthy.