I am in the midst of writing a web application for work. Everything is from scratch. I have been a PHP programmer for about 13 years, Node.js programmer for the past 2 years, and have no shortage of experience with JavaScript. I love Node.js, and recently rebuilt the company's API in it...

So, in planning this web application, the approach I'm considering is, have the Node.js API for getting data from the server, but render everything in the browser. Use AJAX for retrieving data, History API for loading pages, and a MVC-like pattern for the different components.

I have read articles detailing twitters rebuild a few years ago. It was more or less a client-side JavaScript app, but a couple years after launching it, they started moving a lot of processing/rendering back to the server, claiming the app improved dramatically in terms of speed.

So, my question is as the title asks, is a client-side centric app substantially slower?


3 Answers 3


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).

  • 2
    It's not necessarily true that a client centric application will generate more network traffic. Requesting JSON and laying it out on the client could easily result in less data sent over the wire than a server sending the data and all the surrounding markup. Commented Feb 7, 2014 at 12:03
  • @Carson63000 a client centric application would request tons of data, then filter it on the client, rather than sending the search criteria to the server and having that filter it.
    – jwenting
    Commented Feb 7, 2014 at 12:07
  • @jwenting Depends on whether you want instant client-side updating, or a slight delay when requesting filtered data is acceptable (like with gmail)
    – Izkata
    Commented Feb 7, 2014 at 13:17
  • 1
    @jwenting - filtering on the client or server is an architectural decision; not all client-side apps request tons of data and filter it on the client. Commented Feb 7, 2014 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.