Why XML is far superior to JSON

Tagged:  

I've read an article titled Does XML have a future on the web?, and it does not surprise me, because the author himself is the creator of JSON. Naturally, he would love to promote his stuff. I would like to ignore him but would like to address his questions.

Lets see what he got.

"For data transfer applications, XML is losing ground to JSON because JSON is simply a better data transfer format".
I want to know how? Everyone in the world knows XML is more recognized and widely used and it is well supported by every one of the vendors in the web world (Editors, Application Servers, Parsers, Web Servers, Loaders etc.). JSON's role is what? Simply converting raw text in to a JavaScript object. And how is that a better data transfer format? Can I take the same raw text and use it else where? I don't think so.

I heard there are some frameworks available for JSLT (yeah you heard it right, JavaScript - SLT) available as open source, still I would challenge the performance about those frameworks. I haven't tried them myself, but you cannot beat the performance provided by the native browser XSLTs. I could reuse same XML data and apply different XSLTs to get different sets of transformed structures. You can't even think about this using JSON. And that to you can transform using XSLT's in milliseconds. With JavaScript JSON, you'll be lucky if you can get it in seconds.

Also, what about reusability? My server still can send the same XML and I could put a SOAP wrapper on top of that and I could expose it to web services. Now anybody can invoke that web service. Not necessarily only on the web side, it could be invoked by any server side programs as well. XML is the de-facto standard for Data integration projects, Data warehousing projects. More and more corporations are moving towards a SOA (Service oriented architecture) model and more and more applications have to use XML as the data transport mechanism.

JSON may be used by applications which are not enterprise level, only for applications which deal with less data, and have no need for extensibility. But for more scalability, more robustness, and more extensibility, XML is your best bet. XML has more support and that's what your boss would like to hear.

I've become very enthusaistic about JSON because it allows me to work around the cross domain request restriction of the XMLHttpRequest object. Using JSON data feeds I can create AJAX web applications that work within a compiled HTML help file.

You can have other work arounds like reverse proxy on your web server or handling proxy on your server side code. Just to address cross domain security restriction you want to go to JSON? Come on.

Reverse proxy and handling proxy? Are you serious? Throwing more layers and hardware in the mix isn't a solution let alone a good one.

There are no hardware involved in this one. Just adding an line in the web server plugin file will do the reserve proxy.

JSON for me makes more sense in a lot of situations. SOAP may be the better choice for some others. XML IS losing ground to JSON, no doubt about that.

Can you be more specific? It would be great if you can throw some examples too.

It's easy to say JSON is losing ground to XML based on the perception you get reading blogs. The fact that nobody was using JSON (since it's a relatively new invention) may have changed to a few vocal bloggers using JSON, but I would submit that you'd have to show that XML isn't growing faster, which I predict is very, very false because you've got a lot of enterprises who are deep into SOA web service deployments using SOAP. You seem to be forgetting about the whole XML web services thing, which is a rather foolish thing to do from where I sit.

In my view, using JSON is a bad decision because it shows you're only thinking about the UI. Using XML means you can interoperate with any platform, be it front end or system integration. There are a lot more platforms that support XML and do it well.

JSON has a few advantages over XML when it comes to Ajax applications. With web services it allows cross-domain (something that XML will not have until Firefox 3 is released) with no cross domain proxy (providing you user DOM manipulation), it is already a JavaScript object (although if it look at the Libraries at http://json.org you can find libraries to use it natively in Java, PHP, etc..) and it tends to be much smaller going over the internet.

Having said this I think that XML will be around for a while (can you say RSS), but JSON can not just be dismissed even in the enterprise as we look at the future of the web.

One would argue that in order to address cross domain security restriction, you could use Reverse Proxy or you could handle this in server side code. Cross domain security restriction is a good feature which does not allow the hacker to take control.

Nobody can predict about future. And I don't think no corporation will be willing to pay to replace current XML implementations with JSON way of doing. Other than addressing cross domain security restriction (for me, it is not the right way, defeating the purpose of cross domain security), I can't think anything why should I use JSON instead of XML.

Current implementation of JavaScript sucks big time. When the browser matches JavaScript implementation as powerful as browser's XSLT/XPath, then I may favor JavaScript. Then till any data transport methodologies written in JavaScript does not attract me.

{ "x-domain":"why wouldn't you just specify a x-domain policy?"

"annoying":"I would never hand a designer or a project manager JSON. Its ugly, and prone to human error when entering data. I also don't want to have to compare against an XML schema and serve up data in JSON at the same time. If you really want data transport, use a TCP/IP or UDP stream. Now becoming possible in JS. Ooops, I forgot a comma!",

"btcw":"the captcha on this site sucks. case? really? non-alphanumeric? Really?"

}

Looking at JSON as text is ugly. Look at through any of the latest desktop web browser's debuggers, ITS AWESOME! Train your designer to use the developer tools in any modern browser.

Like all the other "competing" technologies they each have their place. It seems silly to debate the possible demise of one format in favor of another. A good programmer will use the best tool for the job.

XML is losing ground in the AJAX arena because JSON is better suited for that purpose. There are plenty of benchmarks to show that JSON is much faster in that respect. However, in my opinion XML has the advantage when it comes to integration and cross-platform data sharing.

XML is going to be around for a long long time.

JSON is faster in what aspect? Agreed with your other points (XML has more advantages ;-) )

In my experience JSON is much faster when dealing with the small amounts of data used in AJAX application.

Less raw information to send back to the brower.

Hmmm. I wonder if those involved with IE's standards compliance thought, "Well, we'll just do things our way because it's the way we want to do it, standards, schmandards."

So when someone argues with me that their main reason is thats JSON is more cross platform... I chuckle a little.

JSON stands for JavaScript Object Notation. But that doesn't mean that it's impossible to parse or create JSON data with any other language. I have personally used JSON implementations in PHP and ActionScript, and I know there are many other.

JSON can enable more elegant solutions in some use cases than XML. I don't want to explain the difference between the formats, but just look at the existing tools and applications built for or using XML – it's such a massive amout that XML isn't going to run out of momentum for decades.

It is like writing your own way of sending raw text from server, and want the whole world to adopt to this new data structure. What is the necessatity that we have to switch to JSON? It does not work that way. Unless there are very strong reasons to adopt to JSON, it is not going to fly.

Most of my AJAX code requires a very small amount of data with little to no metadata. So it makes sense to use JSON rather than XML because I want to minimize the amount of data I'm streaming back to the client. However, if I had a large/complex piece of data that I wanted to send I might choose to use XML because it provides better ways to structure data. I also think about the client. Is it a browser? Is it another application? Sometimes I use XML because it's the least common denominator. Just about every application with which I interact understands XML.

It seems like your trying to pick a single format. Don't limit yourself. Mix and match. Each of them have pros and cons.

95% of your decision to use JSON or XML should be productivity. If you can get the job done in less time using XML, do it. The little extra speed you might see from using JSON isn't worth it if you can do the same thing using XML in less time.

"the author himself is the creator of JSON"

That's bull... Douglas Crockford did not invent JSON nor did he create it... He just discovered it 2 years after JavaScripts 3rd edition came out in 1999.

"XML is more recognized and widely used and it is well supported"

Yeah, the hype started with XML, JSON came into the picture later. This isn't a functionality argument, it happens in technology all the time. Is Ruby a worse language because PHP is widely used and recognized? Just give it some time.

"I could reuse same XML data and apply different XSLTs to get different sets of transformed structures."

JSON doesn't need XSLT because it's not a semantics-oriented format. It's a data transfer format. Data transfer protocol doesn't need to know that this is a book, this is a title, that is the price for each element (example below). You pack data on one end - you unpack it on another.

"Now anybody can invoke that web service. Not necessarily only on the web side, it could be invoked by any server side programs as well."

JSON can be wrapped and unwrapped with a single function in any language now. In PHP5 it's a native language function, in some languages it's still a library (the code required to wrap/unwrap is very small). You can transfer JSON either between servers, or between server and browser. The fact that many corporations still aren't doing it doesn't mean it's bad. It's just experimental. At some point many corporations weren't using Ruby, once again, and look what's happening now. It's coming out little by little. And by the way, I think it's very convenient to have a perfect native object as a result of JSON unpack in whatever language I choose.

Here's my take. XML is a semantic data representation format. With all the tags and attributes that go into it - it becomes bloated. XML is not that strict - you can type XML yourself, and you can read it without a problem - something that's not easy with JSON. But this comes at a cost - XML is not the most obvious thing to parse. For custom XML you need a parser that knows what the hell's going on. Also, XML is bigger. In JSON it could be a simple array, in XML it's:

<books>
<book>Book 1</book>
<book>Book 2</book>
<book>Book 3</book>
<book>Book 4</book>
</books>

See what I mean by bloat? JSON is a true data transfer format - something that wraps easy, unwraps easy, and gets packed nicely for faster transfer. XML is data representation format, not a data transfer one. Bottom line - XML is better for humans to parse, JSON is better for computers.

This article gives the impression that it was written by an angry teenager. At no time in the article was a valid point made. In the places where points should have been made, there was just a strongly opinionated rambling.

I'm a fair person, and I was hoping to see some valid reasons why XML could be better than JSON. Given the title of the article (far superior?), I came in reading with a grain of salt.

Here's the deal. Parsing JSON is fast because it translates to a native object. You can then parse through that object as intended by the language you are using. It is nothing more than a standard way of serializing an object. XML, on the other hand, I've yet to enjoy using. It's slow to parse because of the unnecessary commands in place specifically to traverse an XML object. Using JSON, you can do so naturally.

Now, please, make one valid point why XML is better. Base it on technical knowledge and not angry opinion.

Have you ever used XML? I recommend you to learn XML/XSLT/XPath first and then join the debate.

Yes, I've used XML, XSLT (both server side with php and client side), XPath. I'm formerly a developer for Disney, now with Oakley, and have worked on quite a few fortune 500 websites and strategies.

Don't question my experience. Question your knowledge... that's how you grow.

The webpart which uses XSLT in sharepoint I noticed it was so slow , it took 12 seconds to load my page, after I took it off , everything got back to normal

To me, this is very simple. JSON works better on the web because the support for turning XML into JavaScript objects has historically been difficult and not well supported.

Having said that: Anybody who's serious about doing Web Services and Enterprise SOA with JSON is a dope when there are so many great tools already written to work with XML. There are way too many transformation tools, routing systems, storage engines, schema tools, etc. etc. etc.

Nevertheless, JSON's simplistic makes it easy to use and quick to implement.

How about we leave it at that and not turn it into an obtuse XML vs. JSON war?

NO, XML must be aborted, it has so more additional things.
As for JSON, most is best, but should not bind to Javascript.
Maybe remove JS is the best, just like ON(https://on.dev.java.net).
For example:

Book 1
Book 2
Book 3
Book 4

json{"books":["Book 1", "Book 2", "Book 3", "Book 4"]
}
on{book:Book 1, Book 2, Book 3, Book 4}
As you can see, as a man, it's easy to recog the contents and the better.:)

should be this:

<books>
<book>Book 1</book>
<book>Book 2</book>
<book>Book 3</book>
<book>Book 4</book>
</books>

json:{
"books":["Book 1", "Book 2", "Book 3", "Book 4"]
}

on {
book:Book 1, Book 2, Book 3, Book 4;
}

  1. "everyone" can machine-read XML
  2. There are four powerful, proven schema standards for XML (DTD, WXS, RNG and Schematron)
  3. XML has annotations, e.g. ?xml-stylesheet
  4. XML can be streamed
  5. XML has XSL(T)
  6. XML has XPath and XQuery
  7. XML has XIncludes
  8. XML has namespaces
  9. A parser can tell me what exactly in my document is wrong because of 2)

OK, milliiiiion reeeasons.
But the key problem is how the reason be make out.
Let's look the developing road of XML, HARD, should say the word. util now, it seems looks more powerfull, but time and time, always has someone rush out to say: stop XML. Why? there must be some reason.
IMO, the key is XML not the best solution.
So, we must find out another way to replace XML.
JSON out, but javascript maybe a main trouble. there are many people not like javascript. A good point of XML is language free, JSON not. Then try to focus on ON, yes, at least ON not care language.

I couldn't agree more with Balaji's comments. As an author of a JavaScript library, this subject has been on my mind ever since JSON released. First, my comments are meant as NO disrespect to the talented discoverer of JSON, but rather as a concern for what JSON represents to the developer community as a whole. So I ask, JSON, to what end?

Plain old XML (POX) is just so much more than JSON can ever be. Moreover, XML is one of the most widely used standards across technologies since the Web, and like XML, JSON requires additional technologies just to sustain its own existence. Specifically, it needs more improved ways to query its data (or objects) that must compete with XPath, and ultimately require server-side libraries to feed data in its proprietary notation (while the notation is simply JavaScript syntax, it is proprietary insomuch that JSON offers itself as a standard), and it can never provide more than the monster that XML is.

I also don't buy the performance argument. If you structure your data tag-heavy then it just isn't fit for transport. POX developers know this and don't design messages in a heavy layout when performance is a concern. For non-tag heavy layouts, the performance for POX and JSON are comparable. And it's easy enough to write a simple and generic class to transform POX to objects in the same manner that the notation achieves. Still, even if it were a smidge faster (which I do not believe that it is), so what? Should we co-mingle generic server-side and client-side code in favor of a few milliseconds? Its the same argument over and over again, and most enterprise-class developers tend to land in the "measureable vs. noticeable" camp when balancing performance vs. maintainability (which is a large argument of server-side technologies such as JSF, et al. vs. Ajax).

Is JSON really worth the trade-off from what XML-based technologies can give us? JSON will never give us what XML will.

Is it really worth the effort for developers to learn two competing technologies just to get by? XML is becoming so easy to learn now because it is in everything that we do.

Is it really worth the effort for developers to design and build libraries to do it both ways? Libraries that compete lose additional functionality that could be devoted to a single technology, while still adding additional complexity. YUI, for example is a popular library that devotes resource to doing it both ways, while adding more complexity. At some point, Yahoo will choose – perhaps when it gets tired of feature synchronization or when they realize that JSON will never replace XML messaging.

I can't help but feel that JSON is the result of an impulse that feeds on developer weakness. In a world where technology moves so fast, JSON will distract developers from core technologies that are a better fit, under the guise of a few nick knacks presented as "shortcomings". Unfortunately, young developers tend to quickly latch on to new technologies as a means to feed their hunger to learn more, while long-time more experienced developers feel forced into learning such things as a means to keep up with the young folks – impulse in, impulse out.

Monte Hansen

But JSON is just serialized object! What can be easier and more lightweight than transferring an actual serialized object?? What can be more convenient for programmer than getting a nicely constructed object into her program? Aren't we gonna ideally make an object out of incoming XML anyway? Aren't we gonna have to write a custom parser to de-serialize an XML chunk? Do you need Xpath to query an object in your programmign language? Don't you just do myObj.Section.Books.each.. or foreach myObj.Section.Books as title => contents? Isn't it what makes it so lightweight, flexible and appealing? Where is the new technology in this? It's plain old technology, adopted to whatever language you're using... I don't get most of these pro-xml arguments, besides the fact that xml is better for presentation...

XPath, XSL, XQuery, XPointer, XLink, XForms... Those are not awesome tools to work with xml. Those are ugly scaffolds to deal with XML's problems. They are dealing with XML problems well, however they are all different extra technologies aren't they? XPath, XSL, XQuery, XPointer, XLink, and XForms wouldn't be necessary if you could just have an.... OBJECT in your code, and do whatever you want with it... Use design-patterns to theme your objects, use regular CSS, use any templating language your heart desires... Grrrrrr.

"JSON's role is what? Simply converting raw text in to a JavaScript object. And how is that a better data transfer format? Can I take the same raw text and use it else where? I don't think so."

I can't even read past this sentence. This is so horrifically ignorant that it brings your entire credibility down to zero.

(Read: YES, you CAN take the same raw text and use it elsewhere. JSON is not just for Javascript.)

Please provide well reasoned and researched arguments before you further muddle the global intelligence.

I came here for a bit of guidance now my heads just mashed! :)

IMO XML is a pain and it does my head in at the min. Although I understand it is more powerful I agree with that but it's well messy extracting the data - too much programming needed.

JSON is easier for the developer to access the data.

What I would like is the ability to easily switch between both worlds if I wanted to

An XML function to grab some xml and spit out a JSON string and vice versa. That would do me just fine would that.

Mart

waht is the advantage of JSON?
http://www.w3answers.com

Evolution is the word here, XML has been around for sometime but things evolve and it's exactly what is happening here, you can also call it "the survival of the fittest". JSON is not replacing XML yet , but in the future it probably will . It is just that so much has been invested on XML (time , money,effort) that many people nowadays have a hard time just thinking about how to adopt something new to replace or retire XML .
JSON is doing fine so far at what it's best. Remember we are just living a new chapter of "the fast-changing world of computer science"....

JSON cross domain request is much better than the xml solution

I am appalled at Balaji's ignorance and his dismissive attitude.

If we need to stick with something just because it is already there, where is progress? Being around longer does not make it necessarily good, does it? I understand that this post was written way back. But now, look at Yahoo, Google et al. Why did they have to support JSON? Are we missing something?

Balaji just stopped replying after a while. The charitable thought is that he is learning JSON before he comments again.

So then....

"JSON may be used by applications which are not enterprise level, only for applications which deal with less data, and have no need for extensibility. But for more scalability, more robustness, and more extensibility, XML is your best bet. XML has more support and that's what your boss would like to hear."
s
Are you kidding me! I know this article was written in 2008, but still. JSON is pretty much analogous to XML, except JSON "speaks" web, XML, hmmm not so much. By that I mean to say that here in future land of 2010 the web has become a true platform, we now have HTML5 and all the API's that go with it. WebSockets, WebWorkers.... etc... Guess what, there all implemented in, JavaScript, and what does JSON stand for?!

So to sum up,
1. more and more apps are using JSON and not XML (including so called "enterprise level" bullshit)
2. it's fasters
3. it's native, it talks nicely with browsers and the web
4. sure XML is perhaps easier to read (matter of taste), is good for configuration. Not good for real-time apps data exchange.
s
So the bottom line is, yes JSON is better than XML..... For most things.

I think they both have their place. However Json is faster to phase. And for things like computer games speed is everything.

There are 3 reasons for this speed increase:
1) Its generally less text.
2) It the phasing rules are simple, which means less work for the program to do.
3) Numbers are differentiated from strings. This is huge. It means that when you convert json to its binary equivalent (Bson) it can save numbers as numbers and not strings. As most engineers are aware converting a string to in integer/float is extremely slow. If you have to do that

I have xml files that I converted to json then bson, about 20% of the values are numbers. With the json I say an improvement in load time of 20%. With binary xml I saw total improvements of about 40%. With bson I saw improvements of 90% (file took only 10% of what xml took). When I profiled it was indeed spending time in the string to number conversion. I tried to optimize that however there is only so much you can do in this area.

[...] [...]

XML is better than JSON

[...] Why XML is far superior to JSON | AjaxonomyJan 19, 2008 … JSON has a few advantages over XML when it comes to Ajax applications. With web services it allows cross-domain (something that XML will … January 11th, 2012 | [...]

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre> <div> <blockquote> <object> <embed> <img> <param>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Copy the characters (respecting upper/lower case) from the image.