Hey Heather, it's me again.

You're so fine you blow my mind! HEY JSON!

<-- home

Hey Heather! It’s ME again.

On the last episode of me blogging to you about the Chrome extension, I went on and on about versioning. Honestly, I could have continued. I may have some leftover trauma from managing versions of papers I’d written and collaborated on (oh! maybe I should post some!). Anyway in this post, I’m going to go on about the JSON file itself.

As I mentioned, every Chrome extension requires a manifest.json file. Google has a page which lists the supported manifest fields and provides links to explanations for each of them. The JSON file has three minimum requirements and a few recommended:

{
  // Required
  "manifest_version": 2,
  "name": "Voorhees",
  "version": "80.5.13", 
  
  // Recommended
  "default_locale": "en",
  "description": "Camp counselor training",
  "icons": {"crystal-lake.png"}
}

This is simple enough to follow and I could just go on to the next steps of the tutorial. But it got me thinking about JSON. What exactly is a JSON file? Why do we even have it? A few things that come up when you search for an explanation on JSON are:

This means nothing to me. I need more context than this. What I’ve read up to now just seems to repeat what is written on the JSON website. Although the information is direct, concise, and is represented well in the railroad diagrams, I still feel like I’m missing something. Let’s look into it!

JSON who?

JSON is defined by his work. What does he do exactly? He’s an intermediate to transfer data basically. We format data in JSON in order to be able to send it somewhere else. Most of what I’ve read quickly jumps into how you can work with it but this overview is unsatisfactory to me. None of what is written explains any of the assertions, except for the name which derives from JavaScript. Ok, so let me take a step back and try again. Once again YouTube has provided a great resource in this video that explains JSON and which I am going to try and summarize (I wish it was summer).

See initially web pages were static, just like this blog. There’s nothing fancy going on here. All you get are my words. Which is great for this type of content. But not for dynamic content. Now, dynamic content is what you receive when the client, for instance your browser, makes an asynchronous request to the server for data. Generally, you’ll have the design already set up and will require some data from the server to fill in the gaps. So the server needs to send a response in some format. HTML won’t work because you already have the layout and the design, you just want data. How do we go about that? Well plain text is an option but how are you going to manage that? How will you place the data where it needs to go if you’re not able to parse it adequately? It would be super complicated. So we structure our data in JSON format which is built on two universal data structures: objects and arrays. Depending on the programming language, these data structures can have different names but are essentially the same. This is beautiful! All you have to do to transfer data from your server to your client is to translate it. If your server is Java and you’re trying to send information to a browser then you: convert your Java data into JSON, send it to your client, and then convert your JSON into JavaScript to access it. BAM! done.

From my understanding, that parsing step is also simpler in JSON than it would be in XML. I was trying to understand that part and found this Stack Overflow answer. I’m not sure I understand the “it’s simpler to parse” declaration because what I see in JSON is :

anObject = JSON.parse(myJSON);

And what I see in XML is:

myObject = parseThatXMLPlease();

I guess to understand, I’d have to get into what’s happening when each is being parsed but that’ll be for another time. The thing I did notice is how much clearer calling the data is in JSON than in XML.

age = anObject.age

Versus:

age = myObject.getChildren("person")[0].getAttr("age");

We can see how much more verbose XML is than JSON.The JSON website provides examples of messages formatted in JSON and XML which helps you see the differences. Here’s one of the examples:

Data presented in JSON:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}}

Data presented in XML:

<menu id="file" value="File">
  <popup>
    <menuitem value="New" onclick="CreateNewDoc()" />
    <menuitem value="Open" onclick="OpenDoc()" />
    <menuitem value="Close" onclick="CloseDoc()" />
  </popup>
</menu>

The differences are small in this example: no repetition of “menuitem” in JSON and no closing tags for “menu” and “popup”. This is just in a few lines so imagine if we had 1000+ lines of data how much more repetition there would be. I would guess that this is one of the things that makes JSON lightweight and it probably helps with the parsing too.

Now in regards to the “human readable” aspect of JSON. When I was looking up the information, the assumption sometimes seemed to be that JSON was human readable as compared to XML. I’m not sure of the meaning the author intended. The JSON page just says “It is easy for humans to read and write.” but doesn’t bring up a comparison. When I first saw “human readable”, I just thought it meant “not binary”. Some seem to think that XML is not readable because of the density of information within a document. I looked up the Wikipedia article on Human readable medium and it says that it’s data or information a human can read. No mention of density of content. I haven’t had to deal with much XML so I guess I don’t have an opinion about it and so it doesn’t really matter at this point. I’ll have this in mind whenever I encounter an XML document though.

Ok so this is a lot of information on JSON and there’s still much to learn, which is wonderful. Here’s the best thing I found in regards to JSON. As I was looking into it, I found the presentation The JSON Saga by Douglas Crockford where he tells the story of how JSON came about. I don’t know if it’s the wine but I felt like applauding when he brought up the slide titled “Languages” and says:

you can exchange data between programs written in any pairs of these languages and it works and it’s really easy because JSON is at the intersection of all of these languages.

I mean really. Wow! How amazing is that? That people just came along and contributed to it is awesome. That is no small feat. Communication is a hard problem and this tool, this JSON just comes along and makes things a little simpler. Because people got involved.

« Prev:Building a shell - fork() in the road Next »Building a shell: pipe down!
home