JSON Lives

It has always been interesting to me how long it can take a technology to become truly rooted in the minds and toolsets of the software development community.  This mandatory waiting period for technological stability seems to be just long enough that most of the fads fall through the cracks.  Many tech buzzwords get thrown around, and there is no shortage of hype.  Web 2.0, AJAX, WCF, WF, Ruby on Rails, NUnit, TDD, Scrum, Agile, Pair Programming… If you take all of the topics of PWOP productions over the past year, I see a bunch of stuff that is undeniably cool, but typically not what I use in my day-to-day work.  With a few notable exceptions, a majority of the newer technologies have not made it into corporate IT departments just yet.  Actuarial types like to see the riff-raff settle out before they build their infrastructure on top of it.

Most of what you see fly though your RSS reader or pop up on your iPod are curious glances at interesting ideas that will ultimately be a blip on the radar screen of 21st century computing.  To provide an example: I am a huge fan of CruiseControl.NET, but I believe it’s days are numbered.  It is only a matter of time before Microsoft refines TFS, integrates it into Visual Studio, and makes it cheap enough that you’d have to be a zealot to ignore it’s utility.  Does anybody remember Netscape?

Now I am not trying to make a point that Microsoft eventually gobbles everything up, and they are masterfully elegant at copying other people’s great ideas.  Everyone already knows that.  My point is that it is possible to expend a whole bunch of brain cycles on stuff that does nothing more than… take up your brain cycles.  So how do you pick the winners?  How do you know what to learn today so that 2 years down the road you will be the expert in the technology that is threaded through the fabric of all things software?  How could I have known 10 years ago that time would be better spent learning XML than COM?

I don’t know.

But what I do know is that I like the simplicity and the light natured format of JSON (JavaScript Object Notation).  It seems like something that satisfies the requirements of what 95% of XML is used for, without the verbosity.  The simplicity of a URL querysting like name value pair with just enough governance and convention to provide some stability.

JSON is essentially made up of objects, arrays, and values.  Values can come in any of the following flavors:

  • string
  • number
  • object
  • array
  • true
  • false
  • null

So you are probably starting to see the recursive nature in that values can be objects and arrays.

var tacos = {
[ {"meat":"sausage","filler":"egg","quantity":1}


"dinner" :
[ {"meat":"beef","filler":"beans","quantity":2}

,�à {"meat":"chicken","filler":"lettuce","quantity":1}]

Although there are several ways to describe this in XML, the most common would probably be











Of course there are various ways to represent this in XML, but the example above shows how XML can be quite a bit more verbose than JSON.  The JSON example has 223 characters while the XML example has 304.  That is about a 25% savings by using the JSON data format.  Because of the importance of quick response times for background http requests, JSON has taken off in the AJAX community more quickly than in other circles (which is ironic because the X in AJAX means XML :)).

So is JSON worth spending time on?  Will it develop schema support as robust as XML and develop into the next superstar that shows up as the format for configuration files in Visual Studio 2010?

What do you think?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: