While client side libraries certainly help achieving this goal, it does not come without any costs. This article highlights drawbacks of going for full client side approach and brings up alternatives that are better suited in many cases.
Rendering HTML is therefore achieved on the client side without any page reloads. The problem is that content becomes harder (or impossible) to access by search engines and your stuff might not show up on Google as often as you hope.
The same goes for using the HTML5 History API push state to enable back and forward history in the browser. Push state expects server side endpoints that respond with HTML, not JSON, so it does not really work. It’s possible to create fake endpoints to make it work, but its kind of a hack.
Another common way to achieve browser history is by adding hash in the URL and trigger hash changes to switch states in the application. However, hash in the URL looks ugly and is not easy for users to write or remember.
Rendering HTML on the client side can also become slow when pages grow big and include multiple parts. Each part of the page usually has a template that needs to be stitched together with JSON and rendered to the DOM in the browser, causing many writes to the DOM.
Server side rendering
This approach solves the performance issue for big views as templates don’t need any processing in the browser before being added to the DOM.
PJAX stands for push state + Ajax. URLs are mapped to real endpoints on the server so the HTML5 History API works without any hacks.
Mixing it up
Here comes the unexpected twist in the story, this approach is also not perfect, huuu? HTML is heavier over the wire and harder to manipulate compared to JSON. That is why mixing server and client side rendering together is often a good approach.
This is what Twitter did to improve performance and intergrade with the History API. They use the HTTP “Accept Header” and check if its “application/json” or “text/html” to determine whether to return full page response or JSON including data and the partial HTML template.
Twitter also released a new client side library called Flight that works without data being sent as JSON. This is a component based library that is being used to build the Twitter front-end.
37signals took a similar path in their revamp of Basecamp, in combination with a lot of caching resulting in a very snappy user interface. In fact they used BackboneJS to implement features that they could not accomplish using PJAX.
I recommend everyone interested to watch the video with David Heinemeier Hansson, co-founder at 37signals, explaining their design decisions in details.
Still, there are few issues. For developing responsive web applications one might wan’t to render different markup for different screen sizes. Server-side rendering requires browser agent sniffing to figure out device information, not very future friendly as new devices might be unknown.
If the plan is to release you web application in app stores, using native wrappers such as PhoneGap, there is no need for pretty URLs or search engine optimization. In that case many benefits of server side rendering are lost and client side libraries might be appealing.
The Split vs. The Holy Grail
Today with NodeJS entering the stage, some smart people are seeking to reuse code between the client and server. Airbnb has some of this people on board and its interesting to read how they use BackboneJS in all places in order to reach The Holy Grail.