5 ms·

The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not. That attitude is misguided. Many people do

The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not. That attitude is misguided. Many people do in fact use JSON as a config file format, so it is a config file format. Real world usage outweighs prescriptions about what is and isn’t correct. Looking at the first standardized JSON spec, it’s not particularly prescriptive about usage, simply saying: JSON is syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications. Of course, it would be a better config file format if it supported comments, but people use it even despite that. I think we should try to understand the reasons for that rather than just telling people they’re doing it wrong.

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.
rumanator 7y ago
> That attitude is misguided. Many people do in fact use JSON as a config file format ...and those people need to face the consequences of their poor and missguided technical decisions. In this day and age we have no excuse to repeat the "but everyone is using XML for that" mistake. Just pick the right tool for the job and stop complainig that the tool needs to change to compensate for your poor judgement.
- hombre_fatal 7y ago
  It's not poor and misguided. For example, VSCode has first-class support for JSONSchema giving you auto-complete and things like drop-own boxes for arbitrary project JSON config. It's better done and more mainstream than any other solution I've seen compared to people saying "well technically you could build that for <pet format>." If you want comments, pipe it through json5 first or something. VSCode again supports comments as a courtesy. More tools that use JSON are starting to as well. It's just not a big deal.
  - rumanator 7y ago
    > It's not poor and misguided. For example, VSCode has first-class support for JSONSchema giving you auto-complete and things like drop-own boxes for arbitrary project JSON config. That's just tooling compensating for the shortcomings of a format being shoehorned into a use-case that falls outside of it's scope. It's the XML nonsense all over again. > It's better done and more mainstream than any other solution I've seen compared to people saying "well technically you could build that for <pet format>." That's the same short-sighted line of argument that was used to force the mistake of using XML everywhere. There are right tools for the right job. JSON os the right tool for a lot of jobs, but config files is not one of them.
    - iainmerrick 7y ago
      What are the alternatives? Even though it’s not ideal, I actively prefer JSON over every other random format I’ve come across. This is speaking as somebody who mostly has to tweak existing configs, rather than extending them or writing new ones. YAML (along with I guess TOML etc) looks nice at first glance, but it has too many weird syntax shortcuts that make it hard to figure out what’s actually going on. And googling for syntax like “[ ]” is hard! With JSON, the data model is super simple, and for a given set of data there’s only one way to write it down. Sometimes the data model is too simple, sure. But even for fiddly cases like dates and times, there’s often an obvious solution (in this case, ISO 8601 strings).

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.

rumanator 7y ago

> That attitude is misguided. Many people do in fact use JSON as a config file format ...and those people need to face the consequences of their poor and missguided technical decisions. In this day and age we have no excuse to repeat the "but everyone is using XML for that" mistake. Just pick the right tool for the job and stop complainig that the tool needs to change to compensate for your poor judgement.

hombre_fatal 7y ago
It's not poor and misguided. For example, VSCode has first-class support for JSONSchema giving you auto-complete and things like drop-own boxes for arbitrary project JSON config. It's better done and more mainstream than any other solution I've seen compared to people saying "well technically you could build that for <pet format>." If you want comments, pipe it through json5 first or something. VSCode again supports comments as a courtesy. More tools that use JSON are starting to as well. It's just not a big deal.
- rumanator 7y ago
  > It's not poor and misguided. For example, VSCode has first-class support for JSONSchema giving you auto-complete and things like drop-own boxes for arbitrary project JSON config. That's just tooling compensating for the shortcomings of a format being shoehorned into a use-case that falls outside of it's scope. It's the XML nonsense all over again. > It's better done and more mainstream than any other solution I've seen compared to people saying "well technically you could build that for <pet format>." That's the same short-sighted line of argument that was used to force the mistake of using XML everywhere. There are right tools for the right job. JSON os the right tool for a lot of jobs, but config files is not one of them.
  - iainmerrick 7y ago
    What are the alternatives? Even though it’s not ideal, I actively prefer JSON over every other random format I’ve come across. This is speaking as somebody who mostly has to tweak existing configs, rather than extending them or writing new ones. YAML (along with I guess TOML etc) looks nice at first glance, but it has too many weird syntax shortcuts that make it hard to figure out what’s actually going on. And googling for syntax like “[ ]” is hard! With JSON, the data model is super simple, and for a given set of data there’s only one way to write it down. Sometimes the data model is too simple, sure. But even for fiddly cases like dates and times, there’s often an obvious solution (in this case, ISO 8601 strings).