Live data from Hacker News

The Benefits of Server Side Rendering Over Client Side Rendering

medium.com

11–20 of 33 posts

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#11
post #6

At what point do developers question whether they chose the right framework when their solution requires a large blocking call for many milliseconds in a single threaded server: > SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which mea…

Yes, a single process will experience the issues you mention.

You can also consider running it on a Kubernetes cluster with auto-scaling turned on.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#12
post #7
post #3

Almost everything was on server side rendering 5years ago. Then angular appeared. I have seen an application login page size 5mb, full of js. Because it downloaded the full application to the client before rendering the login page.

Early attempts were pretty ham-fisted and only really useful for backoffice web apps with captive users and LAN connections. The past few years have seen a lot of advancement in tools like webpack to streamline how much code gets served for a given page.

And for a login page with what is effectively a form element with two input fields that IS is overkill.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#13
I tried—I really did try—to use server-side rendering for every project I've worked on. I find it really unpleasant when I hit a site, like a blog or something, which has almost entirely static content and yet it still rendering it locally. The experience is objectively worse, and I had no interest in making that the case for my users.

But there's a middle ground in practice. Public-facing website that users might hit from a search engine? Obviously render it on the server, and if required progressively enhance it. Something more akin to a web application? Server-side rendering makes everything slower and more complex without benefiting any users. If you aren't using Node on the server, it's even more complex.

I really hate that this is the case. I had this firm idea in my head – "every URL is an HTML page, and users should be able to take that URL and request it using Curl or whatever, and see the content of the page". In practice, we were developing a highly-interactive, domain-specific application that relied heavily on client-side scripting to be realistically useful for users. There were no users without JS that I was able to find. We were doing a huge amount of work to follow a rule of progressive enhancement, that in practice slowed down the experience for users and, benefited nobody, and made development ~ an order of magnitude harder.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#14

I tried—I really did try—to use server-side rendering for every project I've worked on. I find it really unpleasant when I hit a site, like a blog or something, which has almost entirely static content and yet it still rendering it locally. The experience is objectively worse, and I had no interest in making that the case for my users. But there's a middle ground in practice. Public-facing website that users might hi…

Can you elaborate? My understanding is just having the initial version of your components server-sided rendered, not all of it. Then JS takes over when it's loaded. It shouldn't change much to your existing code.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#15
post #6

At what point do developers question whether they chose the right framework when their solution requires a large blocking call for many milliseconds in a single threaded server: > SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which mea…

I've always found that nearly all of the time spent when requesting a page of SSR'd content (whether that be a full page or a rendered component returned to an AJAX request) was spent in the processing before the render happens. Given that, the added complexity of CSR has never been worth it for me.

This is situational, I think. My work mostly involves applications that do significant back-end processing for most requests, and my SSR is always done using a framework that has pre-compiled code doing the rendering rather than an interpreted language. (Perl and C#.) This combination adds a lot of pre-render computing and optimized rendering, which adds up to SSR being a good choice.

I'm not sure what that says about when CSR would be a good choice. If your requests don't do much back-end processing, but still have a long (500ms?) response time, that seems like you're doing something wrong rather than an opportunity to use CSR. Maybe you've chosen a poorly-performing rendering framework. Maybe you're trying to render too-large a page (which would be even more of a problem client-side.)

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#16

I tried—I really did try—to use server-side rendering for every project I've worked on. I find it really unpleasant when I hit a site, like a blog or something, which has almost entirely static content and yet it still rendering it locally. The experience is objectively worse, and I had no interest in making that the case for my users. But there's a middle ground in practice. Public-facing website that users might hi…

> If you aren't using Node on the server, it's even more complex.

stopped reading after this. clearly just babble with no real argument to be made.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#18
post #6

At what point do developers question whether they chose the right framework when their solution requires a large blocking call for many milliseconds in a single threaded server: > SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which mea…

I've always found that nearly all of the time spent when requesting a page of SSR'd content (whether that be a full page or a rendered component returned to an AJAX request) was spent in the processing before the render happens. Given that, the added complexity of CSR has never been worth it for me. This is situational, I think. My work mostly involves applications that do significant back-end processing for most req…

While the rendering time is minimal, the rendering code still blocks to wait for the underlying processing code, making the throughput low.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#19
> SSR TTFB(Time To First Byte)is slower than CSR

Well, it of course depends on what your content is, but you can still use a cache service before.

I installed an infrastructure for an e-commerce for a client. They use Magento. I installed a Varnish in front of it and it goes really faster than without. Most pages are, in fact, static pages (home, categories or products), the dynamic part are ajax loaded after content rendering (like prices or stock) so it's a blast for UX.

Of course it will make no (well, less) sense for a SPA. But for content websites, I think it's more logical to do SSR than force to load the whole JS files to see what's on the page.

Edit : typo

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#20

I tried—I really did try—to use server-side rendering for every project I've worked on. I find it really unpleasant when I hit a site, like a blog or something, which has almost entirely static content and yet it still rendering it locally. The experience is objectively worse, and I had no interest in making that the case for my users. But there's a middle ground in practice. Public-facing website that users might hi…

> If you aren't using Node on the server, it's even more complex. stopped reading after this. clearly just babble with no real argument to be made.

I'm sorry if I wasn't clear, but I don't think it's an argument without merit.

I mean that if you want to build a UI in the manner described in the article—where you essentially use a JS UI framework to render the application server-side, and subsequently make it interactive on the client side—then doing so without the server being Javascript is more complex.

I have direct experience of doing this – I built a complex web application that used this approach from within Rails. Essentially this replaced Rails built-in template renderer with a JS environment running in V8. It was pretty cool, in that it meant writing templates once and having them server-side rendered but also interactive on the client side – but it added a huge amount of complexity.

Is there something I was babbling about that I missed?

Post reply on HN