[tgv]

Of course there are cases where SSR makes sense, but servers are slow; the network is slow; going back and forth is slow. The browser on modern hardware, however, is very fast. Much faster than the "CPU"s you can get for a reasonable price from data centers/colos. And they're mostly idle and have a ton of memory. Letting them do the work beats SSR. And since the logic must necessarily be the same in both cases, there's no advantage to be gotten there.

[k33n]

If your argument is that having the client do all the work to assemble the DOM is cheaper for you under the constraints you outlined then that is a good argument.

My argument is that I can always get a faster time to paint than you if I have a good cluster of back end services doing all that work instead of offloading it all to the client (which will then round trip back to your “slow servers over a slow network”) anyway to get all the data.

If you don’t care about time to paint under already high client-side load, then just ship another JS app, absolutely. But what you’re describing is how you deliver something as unsatisfying as the current GitHub.com experience.

[tgv]

Idk. My applications are editor-like. So they fetch a bit of data, but rendering the edit options in HTML is much larger in size then the data, especially since there are multiple views on the same data. So that would put a larger burden on the server and make network transfer slower. Since generating the DOM in the browser is quite fast (there's no high client-side load; I don't know where you get that from), I've got good reason to suppose it beats SSR in my case.

Mind you, I've got one server with 4 CPUs and 8GB memory that can run 2 production and 10 test services (and the database for all), and the average load is .25 or so. That makes that it responds quickly to requests, which also has its advantage.

[k33n]

That makes sense. And btw when I say “already high client load”, my assumption is that most users have 50 other tabs open :)

[tgv]

Lol!