Going Native
6 March 2007John Resig wrote a great article on jsON today that I wanted to comment on:
First of all, I agree that jsON serialization should be put into the browsers, but then we will have what M$ thinks how it should be done vs. what everyone else does.
Keeping jsON “safe” seems to me to be of a security issue with Javascript. It involves overloading core script like the Array or Object constructor. Correct me if I am wrong, but doesn’t this involve a Cross-Site (XSS) or Man-In-The_Middle attack? This has nothing to do with jsON, except when using jsON Request is to grab data from multiple domains. (which Ajax with XmlHttp can not do) It simply is untrusted code. To deal with this untrusted code - why not follow the prototype pattern of loading js files using the library itself? That is - the first JS in a page is a loader object that can grab new javascript files, but then verify the new files do not muck around like changing core functions.
Using Douglas Crawford’s method for extracting the data is considered bad because he changes the behavior of Object.prototype. I agree this is usually bad, but I am sure we can tweak the code to make it behave.
John then describes how jsON is speedier than XML. Sort of. The big reason why people use json is because it IS JavaScript and is several orders of magnitude faster than raw XML. But if we want to _transform_ the json to do data tricks on it, then it is much slower than XSLT. This is because XSL is a standard that has been around for 10 years, while transforming JSON has not even been around 10 months. But JSONT will mature, and there are other, faster ways to transform jsON. Also there are trick you can do with json you simply can not do with XSLT as it currently is supported in all browsers.
Please join with John and go to mozilla and vote for this feature to be added at https://bugzilla.mozilla.org/show_bug.cgi?id=340987
No comments yet