The answer is that it’s entirely situational.

The intricacy and scale of user interaction, customer experience, the functionality of the application, server load, security concerns and other factors have to be taken into consideration in order to address this question with any degree of accuracy.

To be honest this question should not be answered in generalised terms – there is no wrong answer. If you can provide more details of the nature of the application, we might be able to give some useful advice.

If you’re doing server-side rendering to HTML, your architecture looks like this:

1. User requests URL, server generates HTML for complete page
2. Browser renders HTML, page is shown, javascript is initialized
3. Javascript adds event handlers, page is interactive

If you’re doing client-side rendering, your architecture looks like this:

1. User requests URL, server generates HTML for container page
2. Browser renders empty container (“loading…”), javascript is initialized
3. Javascript performs routing, derives what page the user must see, launches ajax request for content
4. The content is returned, the javascript handler renders it and inserts it into the page
5. Javascript adds event handlers, page is interactive

You can shortcut things a bit by inserting the initial data into the page, but the reality is that with client-side rendering the page is always rendered twice, once for the container to bootstrap an environment, and once in your javascript templating code for the actual content, which is one more time than in a server-side rendering architecture.

That means that if you have a situation where users are likely to request a page and then walk away after reading it, like with twitter, they are ill served by client-side rendering, because the performance is always inferior to server-side rendering (provided you optimize both in the same ways where possible).

However, if your users are expected to stay on the page, loading more data piece by piece and having a rich interaction with that data, like a typical web app, then client-side rendering can be a better architecture for delivering the same set of features faster. It is often easier to implement the rendering / event handling logic if it is all in the same client-side codebase, and there is no big performance downside.

A client centric application tends to generate a lot more network traffic than a server centric application that sends just the end result of the processing to the client.
This client centric application will often make more network calls, each involving more data, than the server centric application.
As network latency is by now often the largest performance bottleneck for applications, that often leads to slower client side performance.

Another thing to consider is security. Pretty much every bit of validation you do on the client will need to be repeated on the server. If not you get the infamous situation where a customer fills his shopping cart on the client, edits the amount to be paid to be negative, then submits the whole thing and the server, blissfuly unaware anything is amiss pays the client AND sends him the products.
This may or may not be an issue for your system, depending on what it does and how it is intended to be secured.

Overall then, you’re better off limiting the amount of data being transmitted between client and server both in volume and possibly number of requests (a high number of small requests might make for a seemingly faster user interface, think partial page submits, despite being technically slower in total CPU time needed).