Sunday, July 10, 2011

JSON as fast alternative for XML is wrong

While going over Learn page ( the first page new bee will read ) on prototype site, I found the statement which leads to misdirect development community:
JSON is notably used by APIs all over the web and is a fast alternative to XML in Ajax requests

It would be nice to remove "fast" word since it brainwash populous without good reason.
I am not sure has anyone on site tried to compare JSON and XML against each other, but my conclusion was totally opposite.

On the chain web server - network - reader - browser rendering   the XML is a winner on ALL tiers.
Why? The answer on all is "native support". I.e. no interpreters involved, all compiled and multi-threaded, polished to perfect in memory and CPU use:

  • web server - back-end serialization could start from DB level. In most DB XML is one of native outputs. Than Object serialization. While on ALL platforms there are zillions of implementations, most platforms are supporting XML as embedded API. Java, .NET, PHP, name it.
    ANY popular enough "Middle" tier on server (the one which does the business and UI logic) has support for use the XML as data holder. 
  • Network. On network JS people are counting each byte. And JSON looks less polluted with unnecessary text. But hold, in production all content goes over gzip-ed stream. And surprize! XML actually has few bytes smaller footprint
  • Reader. Browser needs to parse data. XHR has XML support and EACH implementation uses native (C-based xml lib) code. As result it could process larger amount of data with smaller CPU and memory use. XML gives 100 times faster and 100 times larger data volume. That is right. JSON will die on 100K records, XML will hold 10 times more.
  • Browser rendering. What rendering API does support multy-threading and native code? JS+JSON? No way. Answer is XML+XSL. In addition to run-time (lazy) rendering of heavy UI it gives extra option: rendering before page is loaded. And with speed no JS could be compared to.
On development side "fast" usually mean many things.
For startup where people are working on all tiers, having same data format and API is quite development time saver. As mentioned, XML has support on all, JSON - on some platforms. Documentation and feature set for XML is way behind of what JSON could offer. From validation against schema to encoding.

For large projects communication between tiers has become more important. Cross-team development speed relies on strict data format and validation, performance on data transformation, same data/API on different platforms, etc. XML has it all. JSON - no.

Could you have JSON be applied in all or at least in half? No.

Analysis on why JSON has become so popular and advertised is out of scope of this review. Industry is not always going the rational ways.

Happy coding!
Sasha
 

2 comments:

  1. i don't agree with you. and i'm pretty sure i'm not the only one

    "XML is a winner on ALL tiers"
    - really? what about readability? have you seen http://www.json.org/example.html ? xml is a cluttered mess compared to json

    "in production all content goes over gzip-ed stream. And surprize! XML actually has few bytes smaller footprint"
    - how do you explain this when xml is so cluttered? the json examples are smaller in raw text format than the xml examples. once zipped the json examples are still smaller than the xml ones. how do you explain this?

    "ANY popular enough "Middle" tier on server (the one which does the business and UI logic) has support for use the XML as data holder"
    - this is merely momentum. i think it will take some time for support for json to grow but that doesn't mean it won't happen...

    "That is right. JSON will die on 100K records, XML will hold 10 times more"
    - maybe you had an experience with a bad implementation? this is an implementation detail. this has nothing to do with json as a data exchange format.

    "Browser rendering. What rendering API does support multy-threading and native code? JS+JSON? No way."
    - json is not tied to javascript. that's the whole point. same question... what does rendering have to do with with the json as a data exchange format?

    "Documentation and feature set for XML is way behind of what JSON could offer. From validation against schema to encoding"
    - i'm assuming you actually mean the opposite. json is a much simpler format. it's so straight forward that not much documentation is needed. i do think one of the current weaknesses of json is validation against a schema because those are drafts, but even that seems to be coming along nicely ( i do hope it doesnt become a big mess like xsd ).

    "Industry is not always going the rational ways"
    - the indusrty is slow but i also think this was a rational decision. xml is a design by commitee and compared to json, it is a much less rational direction. i cannot stand xml much after seeing json. you just see json is right when you compare the two.

    ReplyDelete
  2. Sorry, you make me laugh.For new bees without CS background:

    > http://www.json.org/example.html
    displays HTML made out of those formats. If you open JSON as separate file or XML as separate file you will see the difference. XML is structured and collapsible tree under most of browsers. From file system it usually opened in browser as well.
    To me it is way more visual than JSON. Editors I am using also treat XML same way: as tree view and some do not show angle brackets and closing tags if you do not like that. VS is my best tool among all I seen for many tiers, including XML.

    "- how do you explain this when xml is so cluttered?" You need to understand how zip tables working than. In few words, repeated entries do not take extra space. So same tags even if they are long and met often will consume same amount of space: key and counter as primitive explanation. Try to zip actual JSON and XML with same data, you will see the difference.

    -Middle tier- "- this is merely momentum..." if you do not work on cross-tier environment, you right. And JSON over time is picking support there. Still far enough to avoid it.

    -JSON will die on 100K- "bad implementation? this is an implementation detail."
    It is not to implementation of data presented. It is about how browser implemented parser and holds data. And it is going closer over time with native JSON support in some browsers. Still far from acceptance level.

    ". what does rendering have to do with with the json as a data exchange format?" It is most popular use case for JSON: populate UI from data.

    JSON... "it's so straight forward that not much documentation is needed." Right, if you do not use those "unnecessary" features like data validation, transformation, etc. But I do. And large cross-site apps do not have a way to avoid that.

    "you just see json is right when you compare the two." That is what I do here. No point of yours taken as valid.

    ReplyDelete