3 ms·
JSON versus PLIST, the Ultimate Showdown
- pooriaazimi 15y agoThis post was previously submitted about 14 months ago, but had got only 4 upvotes: http://news.ycombinator.com/item?id=2334418 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.
- _rs 15y agoIt'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.
- dmethvin 15y agoInteresting 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.
- zdw 15y agoI'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".
- thaumasiotes 15y agoThe article contrasts XML in its aspect as a "plain-text format" with JSON. What does plain-text mean that would exclude JSON?