13

I just started doing jQuery last week, and so far I already made some basic systems with ajax, like basic jQuery CRUD and simple chat system without referencing on other's work for I decided to test myself on how far I can do systems alone in jQuery(without JSON and XML yet).

But when I decided to look at other's work (hoping to get/learn good practices and codes out there) many or almost every program that deals with ajax have some JSON in it. So I decided to study and read JSON specially this one, but I guess because it's my first time dealing with it, I'm having a problem sinking it into my brain. Yeah I know it is a "lightweight way of describing hierarchical data", I also know how to make JSON like mixing a literal array and object in JS, and how to dsplay it in js.

But my question is, what's the difference and what's the advantage than not using it? When I can still get and store data on the server using ajax and database without JSON. By the way I haven't focus on XML yet because based from my research it's better to use JSON in AJAX.

Can you give me some actual scenario dealing with

s1. ajax php mysql (this with what disadvantages?)

and

s2. ajax php mysql json (this with what advantages?)

I mean, my focus is to send and get data, and I already can do it with s1.

Sorry if you find my question stupid. Tia. :)

Barry
  • 1,587
  • 2
  • 13
  • 19

2 Answers2

23

Why use JSON? The answer is portability and structure.

JSON is portable because parsers and writers are available for many, many languages. This means that JSON that a PHP script generates can be very easily understood by a JavaScript script. It is the best way to transmit complex structures like arrays and objects, and have it still be compatible with multiple languages.

JSON provides structure because the data you transmit with it can have consistent formatting. This is instead of transmitting back plain-text (i.e. unformatted) data, like comma-separated or delimited data.

Data that is merely delimited (for example, "BookName1,BookName2,BookName3") is more difficult for humans to understand, debug, and work with. If you wanted to debug a response between your server and your browser and the data was delimited (like my example above), you might have a hard time understanding it. Also, if you want to add different data types, provide separate records, etc., then your custom data format becomes more complicated. Eventually, you might end up reinventing JSON.

As a side note, JSON is indeed better than XML. It is much more efficient space-wise. There are no tag names to take up space. Structure is created via nested braces, instead of verbose tags.

Resources

Here is an interesting article on the differences and pros/cons of XML and JSON: http://www.json.org/xml.html

Examples

Per your request, here is an example of encoding JSON with PHP. This is ripped from the docs:

$arr = array ('a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5);

echo json_encode($arr);

Output:

{"a":1,"b":2,"c":3,"d":4,"e":5}

Contrast this to something like this, without JSON:

a,1
b,2
c,3
d,4
e,5

To parse that, you'd have to iterate through each line, split the values yourself, and then create the array. This isn't that difficult, but imagine you have a nested object:

$arr = array ('a'=> array(1,2,3),'b'=> array('a' => 1, 'b' => 2),'c'=>3,'d'=> array(1,2,3,4,5) ,'e'=>5); // etc.

With JSON, it's no different to encode it. Just use json_encode. But, encoding this manually, and then decoding it manually would be significantly more work.

Chris Laplante
  • 29,338
  • 17
  • 103
  • 134
  • I've heard of browsers having optimized text-receiving and parsing for the [JSON MIME type](http://stackoverflow.com/questions/477816). Or, maybe it's just that there's more overhead with XML. – zanlok Feb 03 '11 at 01:42
  • 1
    Interesting, but optimized in what way? – Chris Laplante Feb 03 '11 at 01:43
  • Oh, I thought you were referring to a specific optimized JSON MIME type. Never mind. But yes, XML has way more overhead. – Chris Laplante Feb 03 '11 at 01:45
  • I guess I'm now starting to get you, so it basically give a standard structure to the data you transmit. Thanks – Barry Feb 03 '11 at 01:58
  • @John: Yep. Structure and portability. – Chris Laplante Feb 03 '11 at 02:00
  • This "better" needs to defined in scope. Otherwise it is just a candy-coated lie. Consider these: There is more defined XML tooling for "structure". XML is as well-defined as JSON, even if more complex. Portability should not be confused with ubiquity (which JSON does have across web-browsers -- however there are XML implementations in JavaScript so this *could* be ruled as a tie). XML "closing tags" allow the ability to detect mis-matches early on, as well as visual queues (wish HTML looked like JSON?). Etc. (I am not arguing against using JSON over XML!!!, just for an accurate answer.) –  Feb 03 '11 at 06:03
  • @pst: If I had gone into every pro/con for each method, I would have ended up with an essay. :) The asker just wanted to know why to use JSON. The XML info I included was for comparison sake. Is XML easier to read? Yes. Is XML also portable? Yes. But I never implied that this wasn't true, nor is that what the asker requested. – Chris Laplante Feb 03 '11 at 23:27
  • @SimplerCoder I am mostly playing the devils advocate :-) Just the way the question starts "JSON is indeed better than XML" changes the context of the entire remainder: For instance, consider these readings and incorrect conclusions: If JSON is portable (and better) then XML is less portable. If JSON is structured (and better) then XML is less structured. If the question started with "JSON is [usually] better than a custom format".... –  Feb 05 '11 at 20:14
  • @pst: You are right. I was thinking of moving those three sentences to the very end, so I think I will. :) Thanks – Chris Laplante Feb 05 '11 at 20:44
5

Programming in any sort of programming language, you have several different types of data at your disposal, including the very useful array type.
Interchanging data between Javascript and any server side language can only happen through strings. I.e. you can send and return any text, but there's no way to send a native array or number type.

JSON is an elegant way to express array and other types using only a string. This way you can pass arbitrary data back and forth between different environments and are not limited to pure text. XML solves the same kind of problem, but is often overkill for simple AJAX requests.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • But one could just as easily use `DecodeXML(EncodeXML(array))` -- the method names are made up, but the same applies. The only "requirement" as far as use of transport is that both sides can process the data in a defined matter. Internally I use an "JXON" format which is JSON mapped to XML (some of the libraries deal with XML but not JSON :-/) Don't get me wrong, for most cases I'd rather look at JSON in a response I'm trying to debug ^^ –  Feb 03 '11 at 06:06
  • @pst Sure. But the XML format is much more verbose and hence has a lot more overhead. The only advantage it has is a more complex format, e.g. allowing attributes on values, but that's often unnecessary for AJAX requests. Do you have a concrete example of "JXON"? – deceze Feb 03 '11 at 06:34
  • Terseness is a human-comfort (I like it). Also XML is fairly compressible and bandwidth isn't getting any less... andyway, the `{'1' => ['a', 2, 3], '2' => "string"}` would be `a23string`. Basically the element is the type and if it represents an object's prop value has the "key" attribute contained within it (null and undefined are also represented as unique elements). First choice here would have been to use JSON -- I'm mostly playing the devil advocate -- but that wasn't an option as XML was required through the stack :-/ –  Feb 03 '11 at 08:49
  • (Although I suppose `{'1' => ['a', 2, 3], '2' => "string"}` is always an option *grin*) –  Feb 03 '11 at 08:55