What is the benefit to server-side JSON communication and serialization?

Question

More and more, I see JSON being used to:

1. Communicate between server-side processes.
2. Serialize and store data.

What is the benefit to using JSON over XML in these situations?

JSON's original benefit was that it serialized directly into Javascript objects, thus easing Ajax programming when working with Javascript client-side (server-side Javascript programming would clearly benefit too, relatively rare as it is).

But XML has a large history, and an ecosystem of supporting technologies and protocols (XSL, XSLT, XInclude, XQuery, XPath, XML Schema, serialization support, etc.). Why is JSON infiltrating the non-Javascript world (and data serialization), when it simply seems to be duplicating the role that XML has historically played, but without all the support technology and work that it's taken XML decades to develop?

When I choose XML over JSON in serialization and communication situations that don't use Javascript in any way, I seem to be going against a growing trend. What am I missing?

Edit: My question is not solely about parsing speed (though that might be one factor). My question is more about the lack of supporting technologies and protocols in JSON which have existed in XML for years, and why the technology community felt the need to re-invent this particular wheel.

Answer 1

I would say, that using JSON is just often simpler even if you don't have so many tools as you have for XML. Also JSON is often just enough, you don't need things like XSLT to store configuration or exchange some hierarchical data. So in fact it actually fits this purpose better than XML.

Plus you have also some benefits like better performance, better readability for humans, less data etc.

But there are fields where XML definitely fits better than JSON of course. Like for example document generation using XSLT.

Answer 2

Based on your edits and comments, for example:

My question is more about the lack of supporting technologies and protocols in JSON which have existed in XML for years, and why the technology community felt the need to re-invent this particular wheel.

and:

I'm curious if it was worth introducing an entirely different protocol with huge amounts of overlap and fracturing the development community for such a small benefit.

...it seems like you are coming at this from the .Net/Java perspective (where things like "compiling code" and "IDE's" are common). But because JSON came out of the javascript world, I believe its popularity stems from its appeal to people who are NOT in the .Net/Java ecosystem (so people using dynamic languages -- ruby, python, php etc.).

For better or worse, there seems to be an underlying attitude amongst people who use dynamic languages for web development that all the Java/.Net stuff is too "heavy-weight", so for them it's actually more appealing to have something that doesn't require all that tooling; which can be more easily understood just by looking at it; for which parsers can be more easily written; and for which you can just output a string without having to learn a bunch of other systems.

I'm guessing that the popularity of JSON for web-facing systems then became so great amongst the dynamic languages that .Net/Java ecosystems had no choice but to get on board in order to be interoperable with the newer web-based systems.