View Full Version : JSON Vs XML

8 Feb 2010, 10:30 PM
1. I wanted to know whether json or xml should be used for data binding for grids , combos etc. This is wrt peformance optimization as well as security.

2. Also could anyone suggest what are the performance optimization techniques that need to be used while designing the application.

My application has extjs as ui and ejb, servlets etc as the middle tier.

8 Feb 2010, 10:41 PM
JSON has a smaller footprint than XML and (depending on your server setup and app architecture) can be easier to generate.

18 Mar 2010, 2:08 AM
XML is more complex but it's easier to check (e.g. with a DTD or schema file).
JSON is smaller and easier to handle.

So, for data exchange between different systems XML is better IMO, while just for simple data transfer (e.g. between client and server) JSON is better.

But JSON isn't perfect in its size because it doesn't support classes:

<?xml version="1.0"?>


JavaScript style:
var p = function (prenom,lastname) { return { prenom: prenom; lastname: lastname; }
var data = [p('A','B'),p('C','D'),p('E','F')]

So, think of the amount of data you have for 3.000 persons in XML, JSON and JS-style. JSON is better but also isn't ideal for many data of the same type. I hope a new version of JSON will use a prototype approach to reduce file size some more.

Mike Robinson
18 Mar 2010, 9:09 AM
Here's my random thoughts:

(1) "Security" is really not an issue here. Naturally you should be talking through https:// connections when your subject-matter is sensitive.

(2) When you are talking to "a trusted server," JSON is fast and convenient because it basically is JavaScript. In most cases, it is processed by being eval'd.

(3) If you are dealing with (or building...) a third-party web service, or you must deal with packets of information that might be stored in a persistent data-store and/or handled by means of store-and-forward protocols like e-mail, XML does have the advantage of being self-describing. You can take a message and validate it, against a defined schema (or "DTD"), and thereby know that the data you received is "well-formed." If you're dealing with large documents you can also use "XPath expressions" to navigate through them. (It goes without saying that I'm speaking in reference to the server-side as much as, or perhaps more than, in reference to the client-side.)

(4) There is definitely something to be said for "using what is provided." If on the server-side you're dealing with a lot of XML already, it would be to your advantage to be able to extract (e.g. via XPath) a known subset of a validated document and to simply ship that to the client, who is prepared to deal with it, instead of having to build a server-side widget to make JSON. Issues of "transmission speed" are pretty much nullified by high-speed networks and built-in "gzip" encoding, but software complexity and maintenance are always expensive. (You are "expensive.")

18 Mar 2010, 2:11 PM
That's a question I'm asking myself everyday.
Still no good answer !

I'm using/mixing both of them.

I like JSON because it is easy to use client-side (vs XmlReader to configure) and minimize data transfer.

I also like XML.
You can XSL tranform it (server or client side) to get JSON.
(Note : I got some problems with chars encoding but think I can make it work if I really need to.)

I often get problems debugging not well-formed JSON response (tried to use jslint.com to validate but did not get quick results).

JSON is very permissive, where XML is not ... at all !