[k33n]

That’s a laughable claim. SSR is objectively faster, since the client does nearly zero work other than downloading some assets. If the responses are pre-computed and sitting in server memory waiting for a request to come along, no client side rendering technique can possibly beat that.

[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!

[holoduke]

Still living the early 2000s eh? Pretty much all interactive responsive apps are all 100% client side rendered. Your claim about SSR being objectively faster looks like a personal vendetta against client side rendered apps. Or javascript. Happy days!

[k33n]

It was faster then and it’s still faster now. Of course, you’d have to learn how a computer works to know that I’m right, but that would be a bridge too far for JavaScript casuals! Just add one more library bro! Then you’ll be able to tell if a number is even or odd!

[holoduke]

At least my prediction is accurate after all:)

[k33n]

Confidently wrong, I like it!

[wiseowise]

> objectively faster

> provides zero evidence

[naasking]

Some pretty compelling evidence is history: we had dynamic and interactive web pages 20 years ago that were faster on computers that were an order of magnitude slower.

[k33n]

I don’t really need to provide “evidence”. I told you why SSR is faster and tbh idc if your time to paint is trash.