4 ms·

The reason for that is that there is often a JSON parser library available for any language (especially JavaScript) but no ini or YAML config parser. So people

by foepys 7y ago

The reason for that is that there is often a JSON parser library available for any language (especially JavaScript) but no ini or YAML config parser. So people use JSON because it's already easily accessible. JSON is one of the worst config formats, even worse than the Apache or nginx config formats. Not being able to simply comment out a config line temporarily for testing purposes or to leave a explanatory comment for special setting is simply bad.

vimslayer 7y ago
Though most tools that use "JSON" as the config format actually use some superset of JSON, like JSON5, and do support comments. eslintrc, babelrc, vscode config... pretty much every JS tool configuration apart from package.json. I don't know why people would prefer that over YAML or others but at least you can actually add comments in them and the reason for their popularity doesn't seem to be baked in parser support because these tools are adding their additional "JSON" parsing anyway.
- abiogenesis 7y ago
  I have a hard time remembering YAML syntax (am I constructing a list or a dict now? Oh well, better look it up) and I know for a fact that it's not just me. JSON is much simpler.
  - hombre_fatal 7y ago
    I even prefer JSON over TOML because JSON is simple. TOML has arbitrary rules like how `table = { foo = bar }` can't be multiline, and all that time you spend debugging your attempts at its nested table syntax, you could've just intuitively nested some dictionaries in JSON.
to11mtm 7y ago
Having worked with a bit of YAML, RAML,(which is a superset of YAML) and JSON style configs/schemas... I'd take JSON over YAML if only because it seems to be more expressive. Still, everyone forgets HOCON [1] is a thing, which solves many of the problems expressed here about JSON -for configuration-. It's easy to clearly specify things like time, reference other parts of the config, or if you want to change just one value, you can add that to the 'end' of the HOCON file and be GTG. [1] - https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md
- styfle 7y ago
  I’ll have to find something wrong with HOCON and add it to my list :) https://twitter.com/styfle/status/1237182409239658500 https://twitter.com/styfle/status/1237182409239658500
- iainmerrick 7y ago
  HOCON is meant to be a friendlier JSON, looks like? At first glance, it has some nice ideas but takes it way too far -- just the table of contents on that repo looks longer than a summary of JSON in its entirety. Skimming through it, concatenation of unquoted values is where it goes off the rails for me. This is quite the gotcha: https://github.com/lightbend/config/blob/master/HOCON.md#note-arrays-without-commas-or-newlines https://github.com/lightbend/config/blob/master/HOCON.md#not... My wishlist for a friendlier JSON would be, in priority order: - Allow trailing commas - Comments - Allow newlines instead of commas - Allow unquoted dictionary keys And I think that’s it. I’m not even sure the last one is worth the extra complexity.

by foepys 7y ago

vimslayer 7y ago

Though most tools that use "JSON" as the config format actually use some superset of JSON, like JSON5, and do support comments. eslintrc, babelrc, vscode config... pretty much every JS tool configuration apart from package.json. I don't know why people would prefer that over YAML or others but at least you can actually add comments in them and the reason for their popularity doesn't seem to be baked in parser support because these tools are adding their additional "JSON" parsing anyway.

abiogenesis 7y ago
I have a hard time remembering YAML syntax (am I constructing a list or a dict now? Oh well, better look it up) and I know for a fact that it's not just me. JSON is much simpler.
- hombre_fatal 7y ago
  I even prefer JSON over TOML because JSON is simple. TOML has arbitrary rules like how `table = { foo = bar }` can't be multiline, and all that time you spend debugging your attempts at its nested table syntax, you could've just intuitively nested some dictionaries in JSON.

to11mtm 7y ago

Having worked with a bit of YAML, RAML,(which is a superset of YAML) and JSON style configs/schemas... I'd take JSON over YAML if only because it seems to be more expressive. Still, everyone forgets HOCON [1] is a thing, which solves many of the problems expressed here about JSON -for configuration-. It's easy to clearly specify things like time, reference other parts of the config, or if you want to change just one value, you can add that to the 'end' of the HOCON file and be GTG. [1] - https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md

styfle 7y ago
I’ll have to find something wrong with HOCON and add it to my list :) https://twitter.com/styfle/status/1237182409239658500 https://twitter.com/styfle/status/1237182409239658500
iainmerrick 7y ago
HOCON is meant to be a friendlier JSON, looks like? At first glance, it has some nice ideas but takes it way too far -- just the table of contents on that repo looks longer than a summary of JSON in its entirety. Skimming through it, concatenation of unquoted values is where it goes off the rails for me. This is quite the gotcha: https://github.com/lightbend/config/blob/master/HOCON.md#note-arrays-without-commas-or-newlines https://github.com/lightbend/config/blob/master/HOCON.md#not... My wishlist for a friendlier JSON would be, in priority order: - Allow trailing commas - Comments - Allow newlines instead of commas - Allow unquoted dictionary keys And I think that’s it. I’m not even sure the last one is worth the extra complexity.