I attended an interesting tech talk today – Douglas Crockford talking about JSON.
It’s pretty evident that JSON, because it uses JavaScript syntax, is certainly natural for JavaScript and especially AJAX (which is essentially JavaScript talking to Web Services). This is despite the fact that AJAX stands for “Asynchronous JavaScript and XML” – AJAJ (“Asynchronous JavaScript and JSON”) and AJADI (“Asynchronous JavaScript and Data Interchange”) don’t have quite the ring to it though. JIHAD (“JavaScript-driven Interchange of Hierarchical Asynchronous Data”)? 🙂
Anyway, the tech talk made me think about how JSON, like XML, is essentially just a standard representation for data, which means that it can be used for a lot of the things that people routinely use for XML. I’ve often thought that XML seemed like overkill for a lot of the problems that it is used to solve. JSON can solve a lot of these problems with a much simpler syntax and less bytes.
XML tries very hard to be completely general, extensible, validatable, and all things to all people. And the result is pretty complex. I was reminded me of the classic book, The Mythical Man-Month by Frederick Brooks and it’s essay about the “Second System Effect“. Brooks talks about how the second attempt at designing a system often turns out worse than the first, because people try too hard to make it solve every conceivable problem, especially ones that the first system couldn’t handle. My thought was that the old way to do data interchange was with something like CSV, which is extremely simple but is not self-describing and not suitable for representing complex data structures. Lacking in so many ways, it’s easy to see how, in designing another data interchange format, one would try to create something with a lot more “horsepower” so that it could solve all the problems of the previous format. In doing so, things could get out of hand and become very complex, especially as it evolves over many years and many different people add their own extensions to the core concept. There is also a bit of potential here for the tendency to see everything as a nail when all you have is a hammer, resulting in people using XML for an incredibly diverse range of things from data interchange to RPC (e.g.: XML-RPC and SOAP) to configuration files to GUI specification (e.g.: XUL, XAML, MXML, etc.). And once you start living and breathing a concept like XML, you will tend to solve problems within that world of XML – it’s not natural to think outside of the box and contemplate how to solve the problem with something wholly different. And why would you want to, when there are tons of XML parsers and such out there? Why not take advantage of the tremendous amount of work that folks that have done to write parsers, editors, validators, etc.?
Interestingly, several people were motivated enough to look for an XML alternative and as the story goes, JSON was independently discovered by a number of people.
It’s not rocket science, but it has the potential to solve a lot of the same problems that XML solves and to solve them in a simpler way. And if there’s something that it can’t quite handle because of its simplicity, then we always have XML.