JSON versus PLIST, the Ultimate Showdown

cocoanetics.com

11 points·pooriaazimi··5 comments

I'd love to see this expanded into protocol buffers and custom serialization methods.

There's a whole chapter in "High Performance Javascript" that goes over the different encoding methods, which finds that a purpose built encoding/delimiting scheme was often faster than either JSON or XML.

On-the-wire formats have different goals than on-disk formats. If you want to future proof the readability of your data, keeping it in a structured method (like a database, or XML with well defined schemas) is probably of greater importance than "it decodes fast".

The article contrasts XML in its aspect as a "plain-text format" with JSON. What does plain-text mean that would exclude JSON?

This post was previously submitted about 14 months ago, but had got only 4 upvotes: http://news.ycombinator.com/item?id=2334418

I found it very interesting and useful and thought re-submitting it (with the standard '?hn=2' at the end) would be OK.

It's worth noting since iOS 5 and 10.7, Apple includes the NSJSONSerialization class which I've seen to be much faster than 3rd party libs, and are now "the way" to decode JSON in obj-c.

As far as using something like JSON (in a general key/value sense) in a TCP stream, to disk, etc., I have some bias towards using something a friend made called "KeyedBits" up on Github.

Interesting how? The article itself says PLIST can't handle several real-life JSON situations including Twitter. The focus of the article seemed to be performance. That's premature until a site determines that JSON parsing or creation is a bottleneck, and I seriously doubt it is; many times data will be coming from a database and require an order of magnitude more time to retrieve than than to encode.

Reply on news.ycombinator.com