Understanding JSON: the 3 minute lesson

Understanding JSON(JavaScript Object Notation):

If you are anything like me (and I fear that you are) then this is your experience with JSON so far:

1. Two months ago you'd never heard of JSON
2. One month ago you'd heard the term but paid no attention
3. One week ago you'd heard it mentioned a few times and started to think, right... some more crap to learn
4. Today you woke up with an alarm bell ringing in the back of your mind that said WHAT THE BLOODY HELL IS THIS JSON THING AND WHY IS IT EVERYWHERE ALL OF A BLOODY SUDDEN!

Well I had a slow bus ride home tonight (friday is always slow) and i took a pile of "JSON" tutorials with me. So now I can gently lead you through some BabySteps in JSON.

here we go...

What does it stand for?

JavaScript Object Notation.

[A ridiculous name. It should be called Lightweight Ecmascript Object Notation, or 'LEON' for short. ;-)]

And what does that mean?

JSON is a syntax for passing around objects that contain name/value pairs, arrays and other objects.

Here's a tiny scrap of JSON:

{"skillz": {
	"web":[
		{"name": "html", 
		 "years": "5"
		},
		{"name": "css", 
		 "years": "3"
		}],
	"database":[
		{"name": "sql", 
		 "years": "7"
		}]
}}

You got that? So you'd recognise some JSON if you saw it now? Basically:

Squiggles, Squares, Colons and Commas

1. Squiggly brackets act as 'containers'
2. Square brackets holds arrays
3. Names and values are separated by a colon.
4. Array elements are separated by commas

Think 'XML with Anorexia'

(Or if you're as old as me, think "'.INI' files, with hierarchy.")

(Or if you're a smug lisp weenie, think "S-expressions", and just be smug.)

JSON is like XML because:

1. They are both 'self-describing' meaning that values are named, and thus 'human readable'
2. Both are hierarchical. (i.e. You can have values within values.)
3. Both can be parsed and used by lots of programming languages
4. Both can be passed around using AJAX (i.e. httpWebRequest)

JSON is UNlike XML because:

1. XML uses angle brackets, with a tag name at the start and end of an element: JSON uses squiggly brackets with the name only at the beginning of the element.
2. JSON is less verbose so it's definitely quicker for humans to write, and probably quicker for us to read.
3. JSON can be parsed trivially using the eval() procedure in JavaScript
4. JSON includes arrays {where each element doesn't have a name of its own}
5. In XML you can use any name you want for an element, in JSON you can't use reserved words from javascript

But Why? What's good about it?

When you're writing ajax stuff, if you use JSON, then you avoid hand-writing xml. This is quicker.

Again, when you're writing ajax stuff, which looks easier? the XML approach or the JSON approach:

The XML approach:

1. bring back an XML document
2. loop through it, extracting values from it
3. do something with those values, etc,

versus

The JSON approach:

1. bring back a JSON string.
2. 'eval' the JSON

So this is Object-Oriented huh?

Nah, not strictly.

JSON is about as object oriented as VB6. It provides a nice encapsulation technique, that you can use for separating values and functions out, but it doesn't provide anything inheritence, polymorphism, interfaces, or OO goodness like that.

It is certainly a step in the right direction though, making javascript easier to maintain, share and reuse.

Thomas Frank wrote a nifty little javascript library called classyJSON for adding inheritance and scoping capabilities to JSON code.

And it's just for the client-side right?

Yes and no. On the server-side you can easily serialize/deserialize your objects to/from JSON. For .net programmers you can use libraries like Json.net to do this automatically for you (using reflection i assume), or you can generate your own custom code to perform it even faster on a case by case basis.

UpdatePanel is still easier than JSON. But JSON is easy enough that you may decide to use it over the UpdatePanel under certain circumstances.


The main problem with the UpdatePanel, as most know by now, is that all of the form data gets posted to the server and all of the server code runs during every update. While there are ways of detecting that the UpdatePanel is causing the postback and thereby limiting the amount of code that runs on the server, you are still left with a full submit of the client form elements to contend with. On a large form, and a form with a lot of view state information, this could be a huge consideration.



JSON, on the other hand, only sends the data that is needed for the WebService function it is calling and only returns the data that the WebService function returns. So you end up sending less data, executing less code on the server, and returning less code from the server. This can significantly increase the performance of your application as well as increase the scalability of your application.

However, it will take a lot more work to JSON-enable something like the gridview. In that case, you may decide that the cost of the development outweighs the performance gains of JSON and decide to stay with the UpdatePanel. There are places for both in your toolbox.