CakePHP: JSON vs AJAX

Question

I know the title of this question might be a little bit misleading; I realize that JSON is a way of formatting data and AJAX is a way of pulling/pushing updates from/to the server without refreshing. I'm asking because I legitimately don't have much previous experience in this area.

Given that I have a CakePHP web application: Is it simply a matter of preference if I choose

• To use JSON to pull/push data and then use a script on the client side to update the page?
• To use AJAX to get a complete HTML-snippet from the server and just insert that to the page?

The only differences I see between the two are that JSON would mean less of a load on the server and bandwith usage, and perhaps what language the developer is more comfortable in using (JSON might mean more client-side scripting?).

Could someone shed some light on this matter for me?

Answer 1

Good question. Especially in times where things like Backbone.js have been becoming more popular.

Lets look at it step by step.

Firstly, the load on the server to produce JSON rather than HTML is probably more or less the same. Most resources don't go into transforming your data objects to HTML or JSON, but they go into accepting the client request, loading up your framework, CakePHP in your case, routing the request, loading up some more components, setting up a database connection, throwing queries at it, accepting results, transforming them into arrays/objects and then only will you start outputting that data to strings for your view (JSON or HTML). The thing is though that server side languages like PHP aren't really impressed by looping through things and outputting values into strings, they can do that without difficulty.

In reality the difference in performance isn't going to be that great when you start outputting JSON. At least, not great enough for most things.

When you'd want to use JSON is when you have a complex piece of functionality. For example something like tweetdeck's feeds where there are lots of small components and pieces of data that need updating; Single tweets, lists of tweets, follower counts, etc. It makes sense to load these little pieces of information rather than redownloading complete sets of HTML every time. You'd use JSON and client side templates because you have many things that could potentially change.

In more 'normal' applications however, like blogs, e-commerce websites, wikis, etc you won't really need fine grained things like this. In that case you'd use AJAX (using your definition).

The reason for some is that it is easier and more developer friendly to build HTML views rather than to first build views that return JSON and then building client-side templates to render these. It is easier to check certain conditions, create loops, fetch extra data when needed, etc in a server side template. It won't cut into your performance all that much anyway.

Another reason is that you can use the static HTML on the server side to render non-AJAX pages too, as a fallback. So when AJAX is available to the client, you load the content through AJAX and replace lets say the content of your '' with the '' from the HTML that you got, but when there isn't any AJAX available, you just redirect to that page. So now you have support for both javascript AND non-javascript client. You could achieve this with server- and client-side templating too, but that would require double work or using something like Mustache.

On top of this, a disadvantage of using JSON to do all your rendering in the client is that some pieces of information are required for rendering your page, but are not supposed to be in the hands of your users. I could imagine things like credit card data, social security numbers, real names, etc that you'd run some sort of check on in your code before you render on the server side. In order to do that same check in the client side you'd have to send it all to the client, ergo giving it to the user. Of course you could not do this and first process all of your data on the server side, before sending it to the client, but that means you are already doing more and more of what you'd do in an HTML template anyway.

To sum up:

For me the performance between server or client side html rendering isn't that obvious in real life. I use a lot of JSON, but usually for non view related things. Like saving something through an AJAX call and then returning a status report in JSON. So I can do stuff like if data.status == 'awesome', etc. If I would fully AJAX a normal website however, I would use something like pjax (below) to load up pieces of HTML from the server. In my eyes javascript should be doing things with existing HTML and should not be coupled with it too much. There are exceptions, when building really complex and real-time applications that require keeping track of lots of smaller pieces of data at the same time, so client-side templating has its place, but not just everywhere.

Have a look at pjax, it is a javascript library for loading pieces of html dynamically from the server side into elements on your page. http://pjax.heroku.com/

DHH replied to a thread on Hacker News on the how and what of their setup with Basecamp; mostly server side scripts, little client MVC.

https://news.ycombinator.com/item?id=3603898

Another interesting link. LinkedIn describe how they use client-side templating for performance reasons. http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates