I am using every new Ajax feature possible in order to the users a rich client application experience. I seems that I will need to abandon all of my work is I can’t get to speed up. It takes 20 seconds for a page to load even when everything is cached, only a few seconds with other browsers.

What do I need to do to make it FAST?

My point exactly. However my XML was better ;) youre a schema guy. i can tell.

To be fair, in my opinion, your XML doesn’t (and can’t (1)) take advantage of the purpose of XML, which is to have a DTD or XSD defining what the data should look like. When interchanging data between two systems, this is the /real/ advantage of XML (again, IMO). I can publish a service with an XSD and you can write a program to parse any document I generate which validates against that XSD. We can do this comletely independently of one another.

If all I want to do move information from one part of MY system to another part of MY system, I know and control the code on either end of the exchange. That’s where XML loses it’s advantage. JSON shines in that space because I can quickly move a data structure across the wire into one programming language or another with minimal parsing effort.

When publishing a service, or accepting data from the general public, XML would be my first choice. DTD/XSDs allow me to publish what I dole out or accept in a nice, widely understood format that you can code to. When I control both ends of the communication, and one of those ends is in Javascript, I use JSON.

So, remember, the right tool for job.

(1) A better XML document:


<object name="obj">
  <property name="prop" value="value" />
  <property name="notarray" value="one" />
</object>
<object name="obj1">
  <property name="prop1" value="value" />
    <array name="array1">
    <element value="one" />
  </array>
</object>
<object name="obj2">
  <property name="prop2" value="value" />
  <array name="array2">
    <element value="one" />
    <element value="two" />
  </array>
</object>


Given these JSON objects:

‘obj’: { ‘prop’: ‘value’, ‘notarray’: ‘one’ }

‘obj1′: { ‘prop1: ‘value’, ‘array1′: [ 'one' ] }

‘obj2′: { ‘prop2: ‘value’, ‘array2′: [ 'one', 'two' ] }

Show me the equivalent XML that clearly indicates that array1 is an array with one element, array2 is an array with two elements, and notarray is not an array at all.

give me a break. YOU think JSON can express maps and array more clearly. thats what YOU think. dont state that empirically. Secondly, ‘no chance’ of misinterpretation? right… how long have you been programming?

When you visit ANY webpage with javascript enabled you are allowing that site to execute arbitrary javascript in your browser – whether you use eval() or not.

Let’s say you are writing a web app and you fetch some JSON data from another web service, “Joe’s Car Parts”. You fetch the price of a car part, but Joe inserts some additional JavaScript into the response. You eval() the response and Joe’s code runs, does some nasty stuff (in your domain, potentially using your session data).

So if you are fetching JSON data from a source that you don’t trust, you should probably parse it.

I fail to see the point of the naysayers here. JSON is XML without the hassle of XML…I think that’s the point of the article. Here’s a quote:

“JSON produces slightly smaller documents, and JSON is certainly easier to use in JavaScript” I think that wins it for me.

Nothing new and a bit late, don’t you think?

Unrelated to this, the article mentioned that “a malicious server could have your browsers executing dangerous actions. In that case, you’re better off using a JSON parser written in JavaScript.” They are talking about the javascript eval() command. When you visit ANY webpage with javascript enabled you are allowing that site to execute arbitrary javascript in your browser – whether you use eval() or not. So the browser client may as well allow eval() use since it is no worse than the non-eval() javascript case. The only place to be concerned about potentially dangerous JSON use is on the server, and using a JSON parser there would make perfect sense.

If you are writing a app which does a lot of object creation etc. I can see where JSON would be attractive at least for the cleanliness of the solution.

But if you are pushing a lot of data back and forth, I think clearly the XML is the way to go. and it has more going for it than just performance.

I wish I had the luxury of having a nice fat pipe to serve every client however I don’t so in my particular case I need to minimize network traffic while also allowing 3rd parties to tap into our core system. Rather then have them writing xml strings for complex api calls, they simply need to pass in a javascript object and I can do the rest.

KISS. You’ll never win a battle of XML vs JSON vs TEXT. Its all about what you need to do to get the job done. If XML works for you then enjoy, if JSON works for you then enjoy. Good programmers will use both in their toolbox if one of them has advantages over the other.

*IF* your application is performing ok in the client the question is what will be performant on the *server* in preparing the data…. now that’s not to say preparing JSON on the server to be sent to the client wont be more performant, merely that is what needs considered.

I don’t know about Ruby or PHP, but Java, .NET and Python all have performant XML implementations, and serialising data to XML isn’t a performance concern. It also means your response is potentially reuasable by other clients etc etc.

As for the notion of posting JSON to the server to be parsed for the request… no is the simple answer… it wont be more performant than simply posting a regular query. Not even close. In Java or .NET to reconstruct an object on the server in an ad hoc fashion is going to completely slag performance.

For myself, for descrete value returns, plain text is just fine for the response. For large returns I’ll simply have the application prep XML and transform in server side to a partial view with XSL into HTML and return the whole portion…. if it’s more than a simple value it’s an exercise in transclusion for me, not RPC… I still feel we’re reinventing a wheel that should have been addressed with XLink…. if I need to repopulate a list then I’ll do just that, I’ll pass back the list content to be sqirted in. Screw having the browser parse anything with JavaScript. Take this content, and put it there.

My clients are as dumb as I can keep them bar plumbing and regular mechanic.