In other news: water is wet.
I genuinely don't understand how anyone is still pretending otherwise. Server-side rendering is so much easier to deliver in a performant way, yet it feels like it's being increasingly forgotten — or worse, actively dismissed as outdated. Out of convenience, more and more developers keep pushing logic and rendering onto the client, as if the browser were an infinitely capable runtime. The result is exactly what this article describes: bloated bundles, fragile performance, and an endless cycle of optimization that never quite sticks.
Server rendered HTML, htmlf endpoints and JQuery load was always the sweet spot for me - McMaster Carr[0] does the same thing behind the scenes and utterly destroys every "modern" webapp in existence today. Why did everything have to become so hard?
Pure client side rendering is the only way to get max speed with lowest latency possible. With ssr you always have bigger payloads or double network rounds.
You're literally downloading a bunch of stuff first just to do a first paint, versus just sending back already built and styled HTML/CSS. Not only is client-only technically slower, it's also perceptively slower.
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.
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.
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.
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!
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!
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.
