9 ms·
JSON vs. YAML – try it yourself
- stormbrew 12y agoI really like yaml. Especially for writing config files. But I still wish there was a cut down version without the bells and whistles that aren't really useful/relevant to human read/written documents. Just a superset of json syntax, not semantics.
- singingfish 12y agohttps://metacpan.org/pod/distribution/JSONY/lib/JSONY.pod https://metacpan.org/pod/distribution/JSONY/lib/JSONY.pod
- wicke 12y agoI'd already be pretty happy if we moved from XML to JSON. YAML would be icing.
- ExpiredLink 12y agoJSON is the new XML.
- frik 12y agoYes, BUT. The other day someone proposed a JSON 'standard' that mimicked SOAP - don't do that. JSON is beloved because it's easy and simply. XML was originally simple too with just DTD as Schema. Then they come up with XML-RPC, XMLSchema, XSLT, SOAP and many other complex concepts that in the end more or less failed.
- mercurial 12y ago> XML was originally simple too with just DTD as Schema. The complexity of XML has not changed since its inception. > Then they come up with XML-RPC, XMLSchema, XSLT, SOAP and many other complex concepts that in the end more or less failed. This doesn't really has any bearing on the specification of XML itself. XML is simple (with some caveats like entity expansion), and extremely flexible. The problem is that it is designed to be read and written by machines, while still being debugable by people. It is extremely verbose. It shines in some use cases, eg for documents with a complex structure and a lot of semantic metadata. But it is even less suitable than JSON for configuration files, for instance.
- _ZeD_ 12y agothe problems with xml (as in "outside the XML-RPC, XMLSchema, XSLT, SOAP stuff") IMHO arises these two / three points * it's a little too verbose (<xml></xml>.. while even S-expressions use just ')' as terminator) * there is no obvious way to transform any xml to an object (pojo is the best aproxymation, but how do you differentiate between a sub-tag, a text node, and an attribute?) * it's essentially typeless (how do you serialize a number? how to differentiate it from a string? from a boolean?)
- mercurial 12y agoI agree that it is verbose, but I am not convinced that S-expressions are the solution. In a complex, deeply nested XML document, you should be able to tell where a given tag is inserted without counting parentheses. > there is no obvious way to transform any xml to an object (pojo is the best aproxymation, but how do you differentiate between a sub-tag, a text node, and an attribute?) That's OK. Just don't use XML to serialize data structures. IMHO, the use cases at which it is good are a lot closer to use cases for which HTML works than when you hesitate between XML and JSON. > it's essentially typeless (how do you serialize a number? how to differentiate it from a string? from a boolean?) That's not entirely wrong, but you can enforce a lot of things via XML schemas (eg, something like XSD or RelaxNG).
- ExpiredLink 12y ago> you can enforce a lot of things via XML schemas (eg, something like XSD or RelaxNG). XML is structured text that can be validated. XML's biggest selling point!
- blencdr 12y agowhy don't you try IBM's JSONx ? http://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.1.0/com.ibm.dp.doc/json_jsonxconversionexample.html http://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.1.0/c... ;-)
- polemic 12y agoThe conciseness of XML with the power of JSON!
- bhaak 12y agoThink again if you really want that for every service. I've encountered many poorly written services where I would have been happy if there were a schema to be at least sure what kind of messages are exchanged.
- nperez 12y agoThis is valid JSON in the same LOC: http://i.imgur.com/gv79uNM.png http://i.imgur.com/gv79uNM.png It just seems like YAML is making things more implicit. I like explicitness. Not against YAML, but it's no holy grail in my mind. I'm more experienced with JSON than YAML and could be swayed on this, but so far I'm not. They seem like two roughly equal ways to do the same thing. This seems oddly similar to the nit-picky problems people have when learning Python from a C-like background and being annoyed that semicolons and flexible indentation aren't the norm. When I spend months working on JS code, looking at Python slightly annoys me, and vice-versa, so I think I get it. I just don't think it's an important, game-changing thing. I'll be learning about Ansible soon, so I'll have to also learn YAML syntax. I guess I'll have a more educated view once I've gotten deep into that.
- deleted 12y ago[deleted]
- simcop2387 12y agoIt may not look like it but it's just as explicit in YAML as it is in JSON. In fact JSON is valid YAML even: http://viewsourcecode.org/why/redhanded/inspect/yamlIsJson.html http://viewsourcecode.org/why/redhanded/inspect/yamlIsJson.h...
- AnkhMorporkian 12y agoYAML has a couple big advantages (in the proper situations) over JSON. Self-referencing, complex datatypes, and (my personal favorite) embedded block literals. I've, perhaps unwisely, embedded entire webpages a single indentation level after a variable and retained all of its formatting. I'm no YAML zealot though, I do use JSON most of the time, but in the past couple years I've started writing most of my config files in YAML where I have the opportunity.
- hliyan 12y agoWe recently moved much of our application's schema definitions and configurations out of code/JSON and into YAML files (we generate JSON during the build process in placess where it is necessary). A pleasant side effect was that the YAML file set began to double as basic documentation. e.g. name: user plural: users label: User ... primary_key: uid display_key: full_name unique_keys: - username - uid client: storage: type: IndexedDB ... actions: create: label: Save permission: create_user ... server: storage: type: mysql ... api: create_user: url: /users method: post fields: username: name: username label: Username type: string length: 20 required: true editable: false
- CephalopodMD 12y agoI hadn't really looked into YAML before, so I fed it some data for a web app I'm working on. Man, It sure is condensed, but because of that, not very readable to me. If this is the standard for YAML, it's definitely interesting, but not my cup of tea. It's sometimes hard to parse where a list ends or an object begins. If you want to argue that it's more space efficient, I'd say, just use gzipped JSON. If you want to say you're using it for the spacing and/or line breaks, I'd just say find a viewer that prettifies your JSON well. Having a delimiter, at least when you're representing chunks of data, is really useful, easier to code for, and easier to read than tabs or other systems. This, not so much. It's kind of a hot mess. Maybe that thinking works well in python, but I'm not so sure the principle translates away from code. If I have a list of objects, I really need to know where one thing ends and the next begins without having to keep track of more than one thing at a time.
- onion2k 12y agoYour argument is inconsistent. You're saying that YAML is hard to read, but you suggest people who find JSON hard to read ought to use a viewer that prettifies it. Why aren't you applying your own logic to YAML, and finding a viewer that makes it easier for you to read?
- CephalopodMD 12y agoYAML requires a specific indentation and spacing to work. There's no changing the layout. JSON is free to do whatever. You could have everything in one line if you wanted. You could use indentations of 8 spaces or 21 tabs. White space does not matter! Point is, it is not hard to figure out a sensible indentation and line breaking scheme if you need it. This is the beauty of braces when dealing with data.
- hittaruki 12y agoBiggest thing about yaml for me was that you can have comments. This is very useful especially when you use it for configuration. For data interchange, I don't see a lot of advantages to yaml though.
- nperez 12y agoI hadn't thought about comments - that is a clear advantage to YAML. Great point to bring up, and supports the popular view I'm seeing that YAML is maybe better for config files. I can think of numerous scenarios where a configuration decision could use some context.
- RubyPinch 12y agoOne thing that comes to mind is (for data interchange), it allows for custom objects to be explicitly marked as such http://www.yaml.org/spec/1.2/spec.html#id2805712 http://www.yaml.org/spec/1.2/spec.html#id2805712 additionally, it allows multiple top level objects in one file (which JSON can't do (not counting 3rd party modifications)) other than that, not much other use
- Ded7xSEoPKYNsDd 12y ago> additionally, it allows multiple top level objects in one file (which JSON can't do (not counting 3rd party modifications)) That's just different syntax for a top-level list of objects.
- oneeyedpigeon 12y agoFor some use cases - and configuration is a prime example - it can make sense to add the comment directly to the data, as another property of the relevant object. that then allows you to use the comment e.g. in a front-end config editor.
- collyw 12y agoI could see comments being really useful in an API.
- SeoxyS 12y agoI like both JSON & YAML for different reasons. YAML is a great configuration format; it's fantastic for being read and written by humans. JSON is much better as a serialization format. Write config files in YAML. Write APIs in JSON.
- txdv 12y agoWhy is it a better serialization format compared to yaml?
- lfender6445 12y agoi would say json is better because it is natively supported by browsers. assuming yaml was as well, would it come out a winner?
- NKCSS 12y agoHmm, I don't like the fact that strings don't have quotes; 1 vs '1', false vs 'false', with javascript's === operator, it's nice to be explicit about the type of data, since javascript is where most json (and later YAML maybe?) gets consumed...
- pan69 12y agoYAML = configuration, JSON = serialization.
- oneeyedpigeon 12y agoI wish they'd called it YACL instead. At least JSON is an accurate acronym!
- KayEss 12y agoOne problem I've hit a few times is parsing of strings with escapes in YAML. In JSON it's absolutely clear how escaping is works, in YAML, in practice, different parsers do subtly different things.
- touristtam 12y agoI have had a similar experience with spaces handling in yaml: the application configuration was producing error because of tabs were being used instead of spaces ....
- sztanko 12y agoYaml is in fact a superset of JSON. You can parse a json with yaml parser. You can also mix json and yaml in the same document and use [..., ..] for annotating arrays and { "bar" : "foo"} for objects. Some yaml libraries allow you to generate yaml that has one style for top level and json style for nested elements / long arrays to improve readability. However I have also learned the following: - in python, parsing yaml file is hundred times slower than json (in fact, my benchmark was showing around 400x slowdown). Therefore you can't really use it in cases where performance matters at least a little bit. A yaml 1k line yaml can load more than half a second (yrmv) - if your yaml doc is longer than two screens, it loses its readability benefits. Therefore it is best to use a whole directory of yaml files, each describing a specific feature. E.g. Ansible is a good example of how to use yaml files.
- frik 12y ago> Ansible and YAML I am searching for an replacement of / alternative to Ansible written in Go or Rust that uses JSON or INI as config format. (Ansible is written in Python. Both Python and YAML rely on outline indentation which causes many headaches)
- yiyus 12y agoHe should compare the specs too. I can learn JSON in less than 2 minutes. I cannot say the same about YAML.
- creshal 12y agoAnd it might just be confirmation bias, but I've seen far more exploits in YAML parsers than in JSON parsers. YAML might be okay for configuration files, but I would never use it for data exchange…
- frik 12y agoHHVM (FB's PHP/Hack) moved from YAML (hdf flavor) to INI for its configuration file format. Sad but true, it was just awful to work with - good that they changed it. https://github.com/facebook/hhvm/wiki/Runtime-options https://github.com/facebook/hhvm/wiki/Runtime-options
- lfender6445 12y agoyaml was awful to work with? can you provide explanation
- chris-at 12y agoShameless plug: Human JSON, http://hjson.org http://hjson.org A different approach to using JSON for configuration files. It sits between JSON and YAML.
- kbd 12y agoI like the idea. I like that you even round-trip comments. I suppose that doesn't add too much complexity to the implementation? Have you ever been bitten by the dwimmy typing of numeric and true/false/null data?
- chris-at 12y agoNo, the whole implementation is actually very simple. It's based on the 'standard' parsers for JS/C#/Python and only differs for handling quoteless stings and the optional syntax. No problems with dwimmy typing ;) - not saying that it couldn't happen but I think that would be the exception. Not having to use quotes/escape characters helps a lot more.
- forrestthewoods 12y agoComments, trailing commas, and 64-bit integers. That's all I want. Is that really so much? :(
- Patient0 12y agoThe stack overflow page is disappointing because in my opinion all of the answers miss the point: Yaml is designed to be readable and editable by humans. Json is only designed to be human readable - and intentionally does not have features to support editing by people. Json intentionally does not support comments. Think about that for a bit and you'll realise what Json is for and what it isn't for. As SeoxyS said: use yaml for config files, Json for APIs.
- joelthelion 12y agoWe don't need two different languages for this.
- dozzie 12y agoOh, yes, we do. We need a language targeted at humans that is machines can process and we need a language targeted at machine processing that is inspectable by humans. Those are two contradicting targets: the latter calls for simplicity, but the former calls for shortcuts[#] to make human's work easier, which adds, not reduces, complexity. [#] Shortcuts like not quoting keys and omitting braces and commas in hash definition.
- mercurial 12y agoActually, after finding out about TOML[1], I would suggest to look at it. It is a lot simpler than YAML, explicitly does not support dangerous features like deserializing arbitrary data structures, while being very readable. Spec is not entirely stable yet, though. 1: https://github.com/toml-lang/toml https://github.com/toml-lang/toml
- NanoWar 12y agoIs compression rate nowadays still a factor? If so, is the performance of YAML worse than JSON?
- kristianp 12y agoI've heard of YAML, it seems ok, but it'll never catch on. JSON is too established.
- touristtam 12y agoI wished the author would have _not_ used flash for the buttons.
- lfender6445 12y agothere was difficulty getting the copy feature to work outside of flash. did you run into a specific issue?
- touristtam 12y agoNothing too specific, but I usually have flash disabled on the browser I use the most and had to view the website in a basic Chrome install instead (which I do have installed for this kind of cases). ;) I thought, honestly, that html5 api was able to provide the same capability as flash, as far as file/clipboard was concerned.
- lfender6445 12y agothanks, i'll investigate
- willvarfar 12y agoYAML IS INSECURE. Your parser might not support instantiating arbitrary objects, but those your programs interact with might... :( Anyone else recall the problems with YAML vulnerabilities? An old blog post by me: http://williamedwardscoder.tumblr.com/post/43394068341/rubys-principle-of-too-much-power http://williamedwardscoder.tumblr.com/post/43394068341/rubys... So never ever use YAML for tainted input.
- jiyinyiyong 12y agoI got my own small language too: https://github.com/Cirru/cirru-json https://github.com/Cirru/cirru-json
- bhaak 12y agoI'm suprised nobody mentioned that JSON lacks date data type. This is annoying as not everybody using ISO 8601 strings as dates.
- ekimekim 12y agoAs several comments here point out, the intended usage of JSON is as a serialization format. In which case, I would expect dates to be in epoch time (if you need to include timezone data, that should be a seperate field). What annoys me is that JSON lacks a binary data type. The best you can do is base64, which really sucks if 99% of your binary data falls into the ascii range, but you have the occasional high bit character and you explicitly aren't trying to treat it as unicode.
- bhaak 12y ago"I would expect ..." that's the problem. Expectations fail when both sides don't have the same expectations. As there is no way in JSON to specify what type a field is and as dates aren't even specified in the JSON, you aren't sure if dates are in epoch time or any common or uncommon variant of ISO 8601 (or worse, non of these two options). JSON hasn't been designed for binary data, so it's not surprising that it lacks a binary data type. There are several options besides base64, you could e.g. use yEnc or BSON. But unless you have really large binary data (in that case I would instead of embed it in JSON, only embed an URL in JSON and let the client download the data separately), I wouldn't bother with another encoding than base64. It is easily compressable and this is handled transparently, so you reach such a low overhead that it is hard to justify using a non-standard option like yEnc.
- Grue3 12y agoYAML seems inherently unsafe as it's indentation based, which makes copy-pasting from different levels very difficult. The best (and one of the oldest) serialization format is S-expressions. You have the best of both worlds, compactness and non-significant whitespace.
- lfender6445 12y agowow, there are some really amazing points here. the take away i've gathered is that yaml is preferred for configuration, with json being the clear winner for data interchange. any suggestions for improvements to the site or content?