Client-Side vs. Server-Side HTML Rendering
The basic concept of the web is the Browser sending a request to the server and receives some HTML, CSS or Javascript as answer. With the usage of Javascript and a thinner REST Service it becomes more popular to put the HTML rendering on the Client. Since I’m interested in this issue and Twitter, as one of the main users of Client-side rendering, gives up on it, I want to blog about it.
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
The first answer from the server isn’t a full HTML Markup but Templates and other “matrix” elements. Not until the next step real files where requested and as soon as they receive and answer it is going to be added to DOM via an Javascript Templating Engine. There are many alternatives just like Hogan.js.
Twitter problems
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).
Another problem, depending on the way you use it, could be the search engine optimization. Google and co didn’t like JavaScript so far. If the answers of a request contains Templates only but no content it is not the best thing to please search engines. Frameworks like ASP.NET MVC with Razor include many mechanics you need to rebuild in JavaScript first. An example is the Validation which isn’t a big issue at all in “usual” MVC applications with Data-Annotations. If you want them to talk with JavaScript ether you need to think about how the error messages (for example in the ModelState) are going to be returned it JSON. It’s a huge and complicated field (but doable!).
Of course JavaScript needs to be activated but I hope this isn’t the problem at the moment.
So Server-side Rendering is the better choice?
In my opinion both alternatives need to be combined to gain the best results. So you are going to have a fast first request and at the same time Google get some Content and small things could be shown via REST Services and JavaScript templating. I’m sure that’s how almost everybody of you work already 
More Information’s:
I’ve found this presentation and I recommend this Blogpost additional.
About the author
Written by Code Inside Team
Learn more about our team.
Sagar Ganatra
January 24, 2013
Thanks for this post, I’m developing a full fledged website and wanted to know your opinion on the approach that I plan to take. We plan to have a hybrid approach where in the client side rendering would take place for modern browsers and server side rendering would happen for crawlers and maybe for old IE browsers. In the former case, the server will return the basic markup along with templates (html, js files) and also the json data in a script block for these widgets (header, footer, navbar) to consume. We thought this would workout since the widget need not make extra http call to get the data. Although some REST calls would be made for some dynamic elements. Is this the right approach?
For crawlers, the data would be compiled on the server and rendered from there. Probably a headless browser like PhantomJS would execute the page.
Let me know your thoughts.