Opinions
36Comment RetweetThe Rise Of JSON
May 17, 2011 By Karsten JanuszewskiI’ve been prototyping a new service, sketching out the different pieces: payload protocol, storage, data model, transport, client/server communication, etc. And, upon completion of the prototype, I stepped back and looked at the decisions made. For example, how are we storing the data? Raw JSON. How are we serving data? As JSON.
It suddenly struck me: there was never even a question of what format we would serialize to; JSON was assumed. And the idea that we would support XML as well as JSON wasn’t even considered.
The fact that this architecture was almost assumed instead of deliberated upon got me thinking: when was it that JSON won? After all, the format isn’t that old. But its rise has been quick and triumphant. I’m not the first one to observe this of course. There’s a great piece called “The Stealthy Ascendency of JSON” on DevCentral which does some digging across a range of available web APIs, discovering an increase in the percentage of APIs that support JSON as compared to XML in the last year. The ProgrammableWeb has a piece called “JSON Continues its Winning Streak Over XML“ which similarly documents this trend. And there is also the much blogged about facts that Twitter has removed XML support from their streaming API and Foursquare’s v2 API only supports JSON.
All this begs a different question: Why is JSON so popular? There is the simple fact that JSON is smaller as a payload than XML. And no doubt JSON is less verbose than XML. But there’s much more to it than just size. The crux has to do with programming. JSON is natively tied to Javascript. As an object representation of data, it is so easy to work with inside Javascript. Its untyped nature flows perfectly with how Javascript itself works. Compare this to working with XML in Javascript: ugh. There’s pretty fascinating piece by James Clark called “XML vs. The Web” that really dives into this.
JSON’s untyped nature flows with how the web itself works. The web does not seem like typing; it doesn’t like schemas; it doesn’t like things to be rigid or too structured. Just look at the failure of XHTML. A beautiful idea for the purists, but for the web, its lack of adoption underscores its platonic ideals.
Not to dismiss XML. It turns out, XML works fantastically well with strongly typed languages. Perhaps XML’s crowning glory these days is how it maps to object graphs — elements as objects, attributes as properties — for the purposes of creating client user interfaces. Consider mobile development. Look at both Android development (Java/XML) and Windows Phone development (.NET/XAML). Both models extensively use XML to represent user interface which map directly to an object graph. And both models use this XML representation to facilitate WYSIWYG editors like one finds in Expression Blend, Visual Studio and Eclipse. I wrote about this a fair amount quite a while ago in a paper called The New Iteration about designer/developer workflow with XAML.
Where you find an impedance mismatch is using a loosely typed payload format like JSON with a strongly typed language. This happens all the time on the server, especially if you are a .NET developer. Historically, this has caused plenty of headaches. I know I’ve spent too much time dealing with serialization/deserialization issues on the server when parsing JSON.
Well, I’m happy to say that this mismatch seems to have finally gone away with the dynamic keyword in .NET 4 combined with some great open source work by the WCF team that has resulted in a library called Microsoft.Runtime.Serialization.Json.
Consider the following c# code, which downloads my Foursquare profile:
WebClient webClient = new WebClient();
dynamic result = JsonValue.Parse(webClient.DownloadString("https://api.foursquare.com/v2/users/self?oauth_token=XXXXXXX"));
Console.WriteLine(result.response.user.firstName);
Notice how the parsing of the JSON returns an object graph that I can drill into. So elegant! If you want to learn more about these new APIs, check out this post called JSON and .NET Nirvana Hath Arrived.
It’s great to see this marriage between JSON and .NET, because it’s clear JSON isn’t going away any time soon.
You must provide a name.
We'll use your email to grab your gravatar. We won't store your email or sell it to trolls.
Follow the Conversation
36 comments so far. You should leave one, too.
Great Post.
I can't find the other post you mention at the end of this one. The link seems to take me straight to the homepage.
@Josh Lewis -- Thanks for the heads up on the broken link. It's fixed now -- the post is here: rhizohm.net/irhetoric/post/2011/05/17/JSON-and-NET-Nirvana-Hath-Arrived.aspx
Good post thanks.
Every time I see WCF team my brain process's it as WTF Team I think they need to rename it lol.
I keep seeing articles like this one declaring JSON winning over XML. They each have their place. Frankly, JSON is taking over where XML was improperly applied. As far as "the simple fact that JSON is smaller as a payload", it depends on how you write your XML. There are plenty of examples out there proving your statement false. Personally I advocate using the best tool for the situation in every situation.
I was considering to use JSON for a mobile app, instead of XML, and I'm glad to know I'm on the right path.
Now have to dig deeper into it, thanks for the links!
overall JSON wins out cause its ease of construction, with a more text style its a tad easier to code with, and well it's oh so much more forgiving, albiet bug introducing. XML has / had its place, but with the speed and direction html5, javascript, and css3 are heading json is going to just continue gaining speed. Also payloads really start to add up when your google looking to trim data down, and your faced with a few billion hits a day for your mapping api. Shaving 10 kb off at that scale pays off big time.
overall JSON wins out cause its ease of construction, with a more text style its a tad easier to code with, and well it's oh so much more forgiving, albiet bug introducing. XML has / had its place, but with the speed and direction html5, javascript, and css3 are heading json is going to just continue gaining speed. Also payloads really start to add up when your google looking to trim data down, and your faced with a few billion hits a day for your mapping api. Shaving 10 kb off at that scale pays off big time.
You might want to try out SimpleJson too. (simplejson.codeplex.com/releases)
We use it for Facebook C# SDK (facebooksdk.codeplex.com) and it works with .net 2.0+, silverlight and wp7.
Also support dynamic for .net 4.0.
"Install-Package SimpleJson"
Is it time to change the name AJAX to AJAJ? Doesn't quite have the same ring to it...
@codefootyping +1.
The other thing about XML vs JSON is that XML processing libraries were originally designed as "cross OOP language" interfaces, and failed to standardize some things that turned out to be useful in practice--most notably, .innerText. Arguably XPath falls under this as well.
If you're sending "a document" which has distinct semantic content and markup, then SGML or XML are handy choices. If you don't have "a document"--if rootNode.innerText doesn't give you a meaningful, usable result--then XML wasn''t the best vehicle for the data.
You can turn any XML document into a JSON structure, but to build a universal XML-to-JSON transformer, you end up with something that looks suspiciously like the DOM when you're done. Or rather, I did.
I don't know enough about .NET to know whether it could be ported, but SimpleXML in PHP exploits the ability to map array access syntax of an object reference into actual method calls on the object, to provide separate namespaces for accessing $node[''attrname''] and $node->childnode. You basically get "a data structure" back just like the dynamic JSON example.
For when XML is partially appropriate, you can also mix the tools, sending an XML string as a value inside some larger JSON structure.
PS. I love the doubled apostrophes. Over-escaping much?
Well... JSON has its uses... just not very many of them, that's all. I use it as control variables for some JavaScript but the idea of storing data in it...? Very strange... not too secure, either, I wouldn't have thought. I wonder which other language features I can work out how to pervert today...
Why is JSON so popular? James Clark sums it up perfectly in one sentence: "...JSON shines as a programming language-independent representation of typical programming language data structures". Any arbitrary JSON can be mapped to your language's native data structures easily, succinctly and consistently.
It seems to me, based on years of observation, that those deriding the use of JSON tend to display more emotion than rational thought when it comes to explaining why they still insist on using XML. I rarely find a reason why JSON wouldn't be better as a data format than XML. Perhaps they should head to JSON.org and do some reading...
> All this begs a different question: Why is JSON so popular?
That doesn't mean what you think it does.
I've long favored JSON over XML due to its conciseness, the angle bracket tax in XML is just too high for some use cases.
It is great to see languages like Python and frameworks like .Net are embracing JSON now.
"All this begs a different question: Why is JSON so popular?"
I think you mean "All this raises a different question:"
"Its untyped nature flows perfectly with how Javascript itself works. "
Uhhh, JSON is a subset of JavaScript.
JSON is also popular because it is the only crossbrowser way to get serialised data from across domains on the client side. Xml didnt allow it, so this 'add a script tag into the head tag' hackery was the ONLY way!
I'm glad Microsoft is finally catching up... The PHP equivalent of that C# code has been easily done for years:
$data = json_parse(file_get_contents('https://....'));
print_r($data);
It's inherently easier to use an untyped data structure in an untyped language (like JavaScript or PHP) so I'm glad it's finally easily usable in C#.
I haven't got a chance to use JSON on a real project yet. As you mentioned, .NET and Java use XML a lot.
Not sure if JSON is going to replace XML everywhere, but there are definitely places where it makes a lot more sense to use JSON.
XML is heavy for inter-system communication. Sorry - it just is. You have to parse, match quotes, slashes - all that is wasted CPU power.
Honestly - the way it was done in the 60's is more efficient than how we do things now... You would need a computer like that used to land us on the moon to parse the kind of textual waste we pump out these days in xml markup.. and that poor pc wouldn't have much left to fly the thing...sure glad there was no XML on the lunar landing module.
JSON on the otherhand is a reasonable middleground . It allows us to take a snapshot of ram, copy it to another machine and repopulate: reinstantiate that same "stuff" in RAM again... All without doing much more than lifting a finger. (Brilliant!) Light Weight and its Genius is its simplicity....
Until... someone comes along and takes this extremely lean and simplistic transport (serialization?) protocol and tries to improve upon it by basically adding more code and possibly adding language specific extensions and stuff that although helpful....
Folks could easily ultimately end up with a bigger, and slower JSON experience even though the software does pretty much the same thing it did before the new improved "reroll" came along...
I hope it stays like it is and the language extensions stay in the languages and don't bleed into the JSON "protocol" at all. (it's not a protocol - for the purists... at least some might argue about the semantics..but I consider it a protocol... a sort of native/javascript with some fancy code, salt and pepper we all love that make JSON what it is)
I do agree XML is easier for humans... But when humans talk... fine... when computers talk.. why all the extra chit chat?
Make everything you do faster... by making your systems do less!
"Where you find an impedance mismatch is using a loosely typed payload format like JSON with a strongly typed language."
First of all, I would like you to go into more detail about this. I have successfully used JSON web-services with C programs. It's hard to get more strongly typed than that.
Second of all, this impedance matching analogy reminds me about the maximum power transfer between two electrical networks. Are you an EE?
Thanks.
"Well, I’m happy to say that this mismatch seems to have finally gone away with the dynamic keyword in .NET 4 combined with some great open source work by the WCF team that has resulted in a library called Microsoft.Runtime.Serialization.Json."
About time! I've disliked that so many web services use JSON, but .NET never had a native way to work with them.
Everyone keeps saying this, so let me clarify. Neither JavaScript nor JSON is untyped. In fact, they have a very good sense of type. JSON fully supports strings, numbers, booleans, arrays and arbitrary objects. JavaScript supports much more. It's only done differently from statically typed languages. Doesn't make it untyped at all.
@Don Sutton. JSON is used for most NoSQL implementations. Look at RavenDb and MongoDb. They're both document databases. That fact alone is evidence that it is a very superior format.
I really like how JSON maps to the standard types of arrays, hashes, numbers, booleans, and strings that you get lightweight syntax for in most any dynamic language nowadays. With XML it's a bit more involved to stringify a data structure you've already got lying about that you'd like to serialize.
There are generally 2 things that make me prefer JSON over XML. First is that with XML I have to check both the properties and the children when parsing which makes a bit of extra work. The second is that JSON explicitly defines arrays, which can make it clearer than XML when you only have examples.
A lots of positive(s) with using JSON rather than XML and is around 15-20% smaller in my experience. JSON though is not totally type-less since there are concepts of numbers, arrays and strings - so I prefer to use "type-lite" rather than "type-less" for that reason.
I've long favored JSON. It's human-readable and carries enough data types to effectively communicate almost any message between systems.
I have had great success with E4X, though, and wish it would gain further adoption among browser script engines (where I write most of my code). Quick access to an XML element using an expressive, human-readable statement goes a long way to closing the gap.
You mean "statically" typed, not "strongly" types. Javascript is strongly typed.
Lately I have been offering XML and JSON for my APIs, but have been realizing that the XML part is only because that is how it has always been. I ALWAYS consume JSON over XML. Maybe it is time to drop XML in my API.
Nice writeup.
As a data exchange format the two are largely interchangeable. The popularity of JSON is just due to the fact that working with the DOM is enough to put anyone off XML.
The reason that I use XML in several web services is because of the ease of adding meta data. I can use element properties to store all sorts of information about the data that I'm transmitting. This data is then an intrinsic part of my data object.
JSON is great if you just want to shuttle around the value of variables but sometime much more is needed.
What is more, serializing a database into XML is much easier and straight-foward than into JSON, and sometimes we need to move around, or save/load, databases.
I don't see it as a JSON vs. XML situation. I believe no one deliberately intended JSON and XML to be absolutely exclusive.
I often face this scenario where, upon return of an Ajax request, there are parts where I need the data as objects/arrays in JavaScript, and parts where I simply need good overall performance when replacing/rendering content in the browser.
This is when I would mix the best of different worlds.
Simply put, I wrap JSON and HTML with XML and return everything through one HTTP request.
i.e. The request returns an XML, but simply as a container for both pure data and plain content, having nodes containing JSON strings within a CDATA, and other nodes that return different chunks of HTML as CDATA.
I still get the benefits of JSON, but I also get the benefits of using innerHTML or $(...).html(...) in places where, if done otherwise, often means intensive DOM element creation/manipulation instead (if it's a big chunk of course). Especially in areas where I won't need the DOM granularity to further attach events onto each elements, I would just replace the whole presentation through innerHTML.
Classic example is to refresh a big table presentation, especially one that doesn't need to be interactive, but needs to display refreshed data. Building it with innerHTML is often faster than through DOM.
The great thing about this, at least from a front-end perspective, is I only need a single HTTP request each time I do so. AND, I can have this "XML container" contain multiple JSON strings and multiple chunks of HTML for all different purposes, all returned to the client at one take.
Both are here to stay, so why not blend them together? It just works.
Just my two cents.
[...] visitmix.com/writings/the-rise-of-json [...]