开发者

Do you Ajax JSON or HTML? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

What is the preferred way to do AJAX.

If it was for a search page written in PHP using Jquery for the AJAX

How would you handle the response

a) Hav开发者_如何学JAVAe the response contain all the relevant html/styling

or

b) Send pure JSON and have a javascript function build the html/styling around the javascript variables.

I can see advantages to both. 'a' is obviously easier whilst 'b' is more efficient (although gzip would probably make the difference negligible).


I would go with the html:

  • doing the conversion from json to html will make the client slower (and you don't know anything about the performance of the user's client)
  • doing it in json means you have to convert twice (from your server's data structure to json, then from json to html)
  • you probably do rendering to html already on the server, so you have the infrastructure
  • network traffic difference will be negligable
  • you can use libraries that do all the work for you (e.g. with JQuery, an ajax call that returns html just becomes jQuery('#div').load(url)).


I would say 'a' is the option you mostly want to stick with.

It's much easier to keep consistent templates server side (you can reuse them in non AJAX scenarios).

Client-side Templating isn't super elegant (if you're going to do it i suggest this: http://ejohn.org/blog/javascript-micro-templating/)

In terms of the styling I would include a minified stylesheet when the page loads not when loading the content.


Personally, I mostly return snippets of HTML from ajax calls, unless I need to do something with the returned data programmatically. For example:

  • Autocomplete functionality. Return a JSON array of data, use javascript to create the appropriate elements.
  • Anything that doesn't really request data, but actually posts it. In-line editing comes to mind. I usually return a status message in JSON format.

That being said, obviously I feel that both options are valid. I'm sure purists will disagree, but sometimes returning plain ol' HTML is good enough.


I would go with Json by default. It's a lightweight (low overhead), easy-to-implement data-interchange format. You just need a good Object-to-Json lib to make 'b' easy.


The important question you have to ask yourself here is, what is your goal. Do you

  • want to have more traffic over the wire and less client cpu usage
  • want to have more client cpu usage and less traffic over the wire

and in that context another question is, how many people are calling your site. If you have hundreds of thousands page visits a day, you should consider to reduce the wire traffic for instance.

In most cases, you don't only want to generate HTML markup, but you also want to send some ordinary data to the client which you can handle in your ECMA-/Javascript. Therefore, JSON should be your first choice (if you don't have to deal with giant blocks of data). JSON is leightweight and can be parsed extremly fast with javascript.

So to repeat myself, whether to generate a complete rendered markup on your server and deliver that to a client or let the client do the job depends on what you are planning to do.

A static page is what you guess correctly, static. But it means no cpu usage for a client/browser. So if you don't need/want to have a "dynamic" page behavior you're just fine with a static page.


The JSON approach is appealing because of the logic separation of data and presentation. If sometime in the future the styling (presentation) needed to change, which inevitably will happen, then the JSON data wouldn't need to change, no?

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜