7 ms·
Thank god. I hate XML. XML has its uses but honestly when it comes down to it working with JSON is a lot easier. When picking a data interchange format you nee
by jtchang 16y ago
Thank god. I hate XML.
XML has its uses but honestly when it comes down to it working with JSON is a lot easier. When picking a data interchange format you need to consider indirect advantages as well. JSON is easier to read on a screen, type out, and overall skim. Skimming XML is a pain.
- thibaut_barrere 16y agoThe only thing I miss from XML is the ability to comment out something. I discovered the other day that it wasn't apparently possible.
- davepeck 16y agoFormats targeted strictly at machine/machine interchange ultimately get used for much more. JSON is no exception. Configuration tends to be the first place that interchange formats are "abused"; even for such a mild abuse, comments are essential. (Hard-core abuses, like XML-based programming languages, are another thing entirely. :-) To deal with JSON's lack of comments, I've considered writing services and apps that produce JSON, but consume YAML. Here, the interesting qualities of YAML are (1) it's a superset of JSON, and (2) it supports comments.
- KaeseEs 16y agoYAML isn't a strict superset of JSON, although since YAML 1.2 it is very nearly so; with just a little bit of care you can avoid the edge cases (eg. you can have hash keys longer than 1024 characters in JSON but not in YAML), provided you are cognizant of them.
- deleted 16y ago[deleted]
- viraptor 16y agoI'm quite surprised. What did you need the comments for?
- thibaut_barrere 16y agoI had a chef json configuration file which I was creating and testing as I went. In this file I had to remove 3 "recipes" and one "attribute" temporarily. Because of the lack of comments I copied the old version to a new file etc.
- axod 16y agoIf you don't care about the standard, you can use / * * / to comment out stuff in JSON. It's a shame this wasn't in the spec. Along with making quotes optional for keys. It's a real shame that the native JSON object, and the spec missed out these useful features... var obj = eval("({foo:3 /*,bar:7*/ })"); Works fine, but JSON.parse and probably most other JSON libs throw a hissy fit for no good reason. I love JSON, but making quotes compulsory for keys, and missing out comments are both a PITA.
- tomjen3 16y agoDepends on your language - in Scala XML is so much easier than JSON, mostly because Scala allows you to do pattern-matching and do functional programming on Xml. But if you are working in Javascript, then yeah it is properly easier.
- andreyf 16y agoA little rude, isn't that? There's different fundamental metaphors: XML is a way of representing a tree with labeled nodes, and also a markup format; JSON is the representation of arrays, simple maps, and basic types in unicode. Each has its uses.
- RyanMcGreal 16y agoTheir uses overlap in that they both broadly serve as a language for defining structured data being transfered between two different systems. For most use cases in this space, JSON is a) expressive enough and b) far easier to render, read and parse.
- michaelhart 16y agoVery well put. Especially B.
- guelo 16y agoI disagree on readability, a big chunk of deeply nested JSON is not easy to read at all. Most smart XML viewers, including most browsers, have folding and coloring which make it pretty easy to read.
- smallegan 16y agoI agree about the smart xml viewers and the fact that most browsers support the friendly treeview's etc... However shouldn't browsers just as easily be able to do the same with JSON? And I believe most JSON viewers I've seen give you the same type of presentation of objects and lists...
- joe_the_user 16y agoWhatever the merits of the two methods, making the API a moving target really sucks for anyone might, say, be in the middle of writing to it.