Client-Side vs. Server-Side HTML Rendering
Usual process during Server-Side Rendering
In the classical way the client calls the server and the server answers with a full HTML markup and send it back to the Client. The Server is able to create the HTML with ASP.NET or other Server-side languages or it is a static HTML file. At this place the Client is comparative dumb because all he does is to load and show the Markup or put it in the DOM for AJAX requests.
Usual process during Client-Side Rendering
Like if already mentioned, twitter was used to do Client-Side Rendering and also created the Hashbangs Trend. But then they got some performance problems and found out that the reason was the Client-Side Rendering. Whenever you call a Tweet the first answer of the server contains Template stuff only. The files will be loaded not until the second request. Now Twitter returned to the old model and as result the request of a Tweet (on a new Session) gets 1/5 seconds faster.
Because I had to make the same decision on a resend project here is my list of advantages and disadvantages:
Client-Side Rendering – advantages
Because of the Templating and Rendering on the Client the Services become much slimmer – probably you turn automatically in the direction of REST.
Also the (feeld) flexibility increases because it’s easy to combine services and most of the time you need your information’s pure and without any Markup to create a modern and good looking Web-App.
Client-Side Rendering – disadvantages
It definitely has a bad influence on the performance – like it happened to Twitter. But at least these are problems for “big users”. A huger problem is the higher complexity in your project. Server-Side rendering is very grown up because of IDEs like Visual Studio co. and because of this it offers easy debugging. On the Client-side you need to find a suitable engine. With either Knockout.js (also it does a lot more than just rendering) or Hogan.js (which comes from Twitter).
So Server-side Rendering is the better choice?