JSON is a subset of the Object Literal
WIth a lot of talk about JSON these days, it's important to understand the syntax and how it differs from the object literal — or rather how it's a subset of it.
The object literal is encapsulated by curly brackets with zero or more property and value pairs separated by commas. Each property and value is separated by a colon. Property names can be an identifier, a string, or a number.
Syntax:
{
property:value,
property:value
}Example:
var obj = {
"iterations":5,
8:10 /* this is valid */,
loop:function(){
for(var i=0;i<this.iterations;i++)
{
alert(i);
}
}
}
obj.loop(); // alerts 0,1,2,3,4
Just to clarify, identifiers and numbers both get converted into string literals. Therefore, in my example, obj["8"] would return 10. Neat stuff.
JSON is for Data Exchange
JSON, however, is meant as a data exchange format like XML. Therefore, it's designed to be pickier. First of all, property names can only be strings. Even pickier, all strings have to be in double quotes (not single quotes). Values can be strings, numbers, object literals (the curly brackets), arrays, true, false, or null. No functions or other types of objects allowed.
Example:
var jsonObj = {
"pie": ["cherry","meringue","apple"],
"heated":true,
"personEatingPie": {"firstname":"Jonathan","lastname":"Snook" }
}Let's not let JSON slide into acronym obscurity like Ajax. (Picture JSON as the prim and proper school girl and Ajax the dude who smokes and rides a motorcycle to school.)
Conversation
You've also got to be careful with those commas. Although it's technically legal to end the last value with a comma, you'll cause IE and Safari to fail miserably.
Whenever I get an obscure error, it's the first thing I check for.
True dis. I found it particularly a bit too picky when I had to put double quotes around my keys. I had been playing with Zend_Json and it simply wouldn't work otherwise.... same goes for the JSON C extension for PHP.
So to continue your thinking, the prim and proper schoolgirl can get on AJAX's motorbike and they can travel pretty far together. Who knows, it might lead to a fulfilling, long-lasting relationship? Perhaps that's enough of that very dodgy analogy :)
I've just used JSON as the data exchange format for a little AJAX application and I like it. It's not so much the format, because I find it slightly more difficult to read than XML (maybe that's because I think in tags). It's just the fact it's so easy to parse in JS. As easy as falling off an oiled log whilst drunk and being pushed by a fat bloke. Yes, that easy.
Nice post Jonathan, it's quite easy confuse the two or assume they are the same thing.
For anyone that's interested the full JSON spec is available here: http://tinyurl.com/zdqjy
I never thought about this difference. I use a bit of everything on the same app: AJAX, AHAH, JSON-RPC/Java and sometimes just XHR+literal JS (this needs another acronym). I never sat down to ponder why was it that the "JSON" acronym was invented. To me, it was just literal notation.
Thx for the clarification.
I agree with Dustin, I personally don't like putting quotes around keys either. I think the rest is fine, JSON rules.
Jason has truely revolutionized the way i handle AJAJ. XML parsing, or using a simple eval statement and getting a native javascript object. I don't know about you, but JSON is far superior for most things, most definitely.
I believe it is also permissible to use bare numbers when retrieving from the objec, as so:
obj[8]==10
Tim: you'd be correct. Although, just to mention, with {8:5,"8":6}, doing obj[8] would return 6.
Ah, intriguing. I take that to mean that no matter how the key is specified, it is always converted to a string for internal use. I'll add that to my own object literal overview.
Yeah ai Find it confusing that keys have to be in quotes. I mean jSon stands for Javascript Object Notation, right? Shouldn't it be exactly the same thing? The only thing worse than learning a whole new language is learning a slightly different one. Confusing.
Ismael: because it's meant as a data exchange format that could exist or need to be transformed into other languages besides javascript, it needed to use features that would be more likely to be supported cross platform. Having keys as strings is more likely to be supported in other languages. In fact, internally, JavaScript converts keys into strings anyways.
It's not that it's different. It's just a smaller set of features.
> {8:5,"8":6}, doing obj[8] would return 6
I don't think this is because javascript is converting 8 to "8" as Tim conjectured. If you try reversing the order of the elments
{"8":6, 8:5}
you'll see that obj[8] now yields 5.
Jack: yes, it's because it's getting converted to a string internally (as mentioned in the article and as re-iterated by Tim). Because both are converted to strings internally, the second "8" always overwrites the first.
"(Picture JSON as the prim and proper school girl and Ajax the dude who smokes and rides a motorcycle to school.)"
But JSON is a boy's name. ;-)
AJAX is a Dutch football team's name, but no-one ever complains about that :)
asdfasd
May I give it a try? Just starting off putting js stuff into my work. We'll see.