views:

43

answers:

3

Hey everyone, I've been thinking about how the majority of web apps works at the moment. If as an example the backend is written in java/php/python what you probably see is that the backend is "echoing / printing" the html ready to the browser, right.

For web apps that works using almost exclusively ajax, is there a reason to not simply communicate without html, as an example just by using JSON objects passing back and fourth between the server and client, and instead of "printing or echoing" html in our script/app backend we simply echo the json string, ajax fetches it and converts the JSON string to an object with all of our attributes/arrays and so on.

Surely this way we have less characters to send, no html tags and so on, and on the client side we simply use frameworks such as jQuery etc and create/format our html there instead of printing and echoing the html in the server scripts?

Perhaps people already do this but I have not really seen a lot of apps work this way? The reason is that I want todo this is because I would like to separate the layer of presentation and logic more than it currently is, so instead of "echoing" html in my java/php I just "echo" json objects, and javascript takes care of the whole presentation layer, is there something fundamentally wrong with this, what are your opinions?

Thanks again Stackoverflow.

+3  A: 

There are quite a few apps that work this way (simply communicating via AJAX using JSON objects rather than sending markup).

I've worked on a few and it has its advantages.

In some cases though (like when working with large result sets) it makes more sense to render the markup on the server side and send it to the browser. That way, you're not relying on JavaScript/DOM Manipulation to create a large document (which, depending on the browser, would perform poorly).

Justin Niessner
Yeah I suppose with large result sets the DOM could slow down, but when you say large result sets you're talking about some huge table I imagine? What do you consider a "large" result set? Our users all have Firefox thank god so lots of headaches are gone there ;-)
quiggle
You will always have more browsers than servers. ;)
unomi
A: 

This is a very sensible approach, and is actually used in some of our applications in production.

The main weakness of the approach is that it increases the load on the browser resource-wise and therefore might - in light of browsers often already-sluggish JS performance - lead to worse user experience unless the presentation layer mechanics is very well tuned.

DVK
@DVK, I've found the opposite. If well written , the browser is often quicker at converting and rendering data (json/xml) into html, than the the network is at transferring generated html.
Chad
@Chad - not if the browser is already somewhat loaded from 10 other tabs running :(
DVK
A: 

Now a days many webapps use this approach like gmail and other big apps even facebook this the main advantage of this approach is user dont need to refresh all the pages and he gets what we want to show him or what he desired.
but we have to make a both version like ajax and normal page refresh what if the user refresh the page.
we can use jquery template which generates html and also google's closer which is used by a gmail and other google products.

MakDotGNU