3 ms·
JSON is by far the easiest to reliably parse. It doesn't rely on tabs or spaces which YAML suffers from. XML is just more verbose JSON without an array object
by ActorNightly 3y ago
JSON is by far the easiest to reliably parse. It doesn't rely on tabs or spaces which YAML suffers from. XML is just more verbose JSON without an array object, and has some redundancy in spec which is not a good design.
Lack of comments for JSON isn't a huge issue considering you can make the keys fairly verbose. And it would be actually pretty easy to add this into the spec, and parsers would still be backwards compatible.
- perryizgr8 3y ago> And it would be actually pretty easy to add this into the spec I present jsonc: https://www.npmjs.com/package/jsonc https://www.npmjs.com/package/jsonc
- gnfargbl 3y agoLack of comments is a massive issue for JSON as a config format. Making keys verbose tells you what a thing is, but comments are there to tell you why a thing is. The only real way around this seems to be to create some kind of a "_comment" key.
- yankput 3y agoI like the json variant that vscode uses. It has a name that I forgot… Json but with comments and allowed commas on the end.
- tirpen 3y agoI believe that's JSON5. https://github.com/json5/json5 https://github.com/json5/json5 It's my preferred configuration file format, it fixes all the problems I have with JSON (trailing commas, comments) without turning it into a mess full of gotchas like YAML.
- yankput 3y agoActually no, it’s something called jsonc. It’s without a spec https://github.com/microsoft/vscode/issues/100688 https://github.com/microsoft/vscode/issues/100688 https://github.com/microsoft/node-jsonc-parser https://github.com/microsoft/node-jsonc-parser
- emptysongglass 3y agoWhy in god's name did Microsoft insist on going their own way on this?
- yankput 3y agoWhat do I know. A theory - they don’t want a third party code in a hot path (they do care about performance in vscode), they already have a very performant parser and they don’t want to add a complexity there. But that’s just a theory.
- jeroenhd 3y agoAll of them are easy to parse. I personally prefer the clarity of indented YAML over the endless nesting of {} JSON brings, but all formats are easy enough to read or write. Lack of comments in JSON is a huge problem for config files. It's not an issue if you're just exchanging data between APIs, but for config files, comments are essentials. There are some JSON specs that will do comments, but they rarely specify what dialects of JSON their parser accepts. There are also workarounds that abuse the fact duplicate key handling isn't part of the spec by specifying each key twice, once with a comment and once with data as most parsers only make the second key stick; those are even worse. You can't add backwards compatible comments to JSON, there's no space in the JSON spec to retroactively insert comments somewhere. The closest you can do is the duplicate key trick, but as the spec doesn't state which of the keys to read as a value, that trick only works with specific parser implementations.
- ActorNightly 3y agoYAML has newlines that indicate the end of a field... unless otherwise specified, which then gets into issues with line endings. Indents can also cause issues, considering a space inserted somewhere by accident can mess up your whole document. JSON and XML rely on specific tags for elements, which are much more reliable, and thus easier and faster to parse. You can easily add comments to JSON spec, by just writing every parser going forward with the added comment parsing. It would read old JSON non commented files just fine.