The Benefits of Server Side Rendering Over Client Side Rendering

#1

Post by wilsonfiifi » Sun, Mar 25, 2018, 11:54 AM UTC

The Benefits of Server Side Rendering Over Client Side Rendering
medium.com

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

#2

Post by aleksei » Sun, Mar 25, 2018, 4:24 PM UTC

For dynamic content it may make sense to offload computation to the client (although in the linked article the opposite was found to hold), but it really irks me when otherwise static pages are rendered again and again on the device of every visitor. Such a waste.

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

#3

Post by ssahoo » Sun, Mar 25, 2018, 4:39 PM UTC

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.

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

#4

Post by ChrisSD » Sun, Mar 25, 2018, 4:54 PM UTC

CSR bugs me most on mobile. What should be simple content, like a reddit page or a tweet, leaves me staring at a large pulsing logo for awhile as the whole app is loaded and content is rendered.

I get offloading some rendering (that server time adds up) but meet me half way. At least show me some content while the rest loads.

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

#5

Post by tetha » Sun, Mar 25, 2018, 5:06 PM UTC

Hm, any thought on the performance/throughput consideration?

I'm not experienced with Node.JS, but something hogging the main event loop of an asynchronous server with a long computation sounds horrible. It'll mangle your throughput, and it'll create some really strange latency spikes for unrelated requests, because the slow computation blocked the event thread from delivering the response of another request. Is this not as much of a problem practically, or would you isolate that SSR code from REST code in different application instances?

In a threaded server like java application servers or go applications, that should be a non-issue since requests are handled in mostly independent threads. It might increase the necessary compute resources some, but that's expected when moving work to the server side.

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

#6

Post by ec109685 » Sun, Mar 25, 2018, 5:06 PM UTC

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 means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can at most do at most 2 requests per second. BIG CONSIDERATION

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

#7

Post by tootie » Sun, Mar 25, 2018, 5:13 PM UTC

ssahoo wrote: 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.

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

#8

Post by codedokode » Sun, Mar 25, 2018, 5:35 PM UTC

I don't really see what are the benefits of using React in an internet shop. SPA are good for interactive and complicated interfaces, but an internet shop is mostly a set of static pages - product lists, search and product pages. I hope they don't use React for the static part of the page and only use it for rendering the cart and other interactive parts.

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

#9

Post by codedokode » Sun, Mar 25, 2018, 5:36 PM UTC

ec109685 wrote: 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…

That is the problem of Node.JS, not a problem of React. They can run multiple instanceof of Node.JS. And if it takes 500ms to render on a server with powerful CPU, it will take even more on the client, futhermore every page update can take that much time too.

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

#10

Post by codedokode » Sun, Mar 25, 2018, 5:37 PM UTC

tetha wrote: post #5

Hm, any thought on the performance/throughput consideration? I'm not experienced with Node.JS, but something hogging the main event loop of an asynchronous server with a long computation sounds horrible. It'll mangle your throughput, and it'll create some really strange latency spikes for unrelated requests, because the slow computation blocked the event thread from delivering the response of another request. Is this…

You can run multiple Node.JS processes.