8 ms·

It's really sad to see the pervasiveness of JSON. For one thing its usage as a config file is disturbing. Config files need to have comments. Second, even as a

It's really sad to see the pervasiveness of JSON. For one thing its usage as a config file is disturbing. Config files need to have comments. Second, even as a data transfer format the lack of schema is even more disturbing. I really wish JSON didn't happen and now these malpractices are so widespread that it's hurting everyone.

umvi 5y ago
So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day (and it doesn't have to be comment-less... JSON with comments is a thing and VSCode has syntax highlighting for it - just strip out the comments before parsing).
- posharma 5y ago
  It's simple. For config files, choose the format that has the best tooling in your company and that supports comments. For data transfer, choose that supports schemas, backwards compatibility and good tooling (protobufs is just one e.g. that I'm most familiar with).
- stavros 5y ago
  > So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Aren't we past basic false dichotomies?
  - saurik 5y ago
    Nope: basic false dichotomies and JSON are both pervasive.
    - a9h74j 5y ago
      There is a corporate- and government-approved standard for false dichotomies, but it works as a de-facto standard, not published.
      - psd1 5y ago
        ifnot: - foo then_clearly: - 'some bar'
- deleted 5y ago
  [deleted]
- zz865 5y ago
  XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.
  - nsonha 5y ago
    not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.
    - KronisLV 5y ago
      > It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).
- donmcronald 5y ago
  For me XML and YAML are about the same. I think I'd also prefer comment-less JSON over both. However, XML wasn't that bad. With a decent editor and schema validation I would say there's a good chance I was more productive with XML than I am with YAML.
- mindcrime 5y ago
  So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Sure, why not? XML rocks. I'll take it over JSON for many purposes.
- int_19h 5y ago
  Actually, yes, I do. XML syntax was far from stellar, and much of the ecosystem (e.g. XML Schema) was drastically overengineered... but even so, we had gems like RELAX NG to compensate. On the whole, it was better than the current mess.
runarberg 5y ago
Tools that use JSON as configuration format could simply allow certain unused keys (e.g. all keys starting with #) and promise never to use them. Then author can write their comments with something like: { "name": "my-tool", "#comment-1": "Don’t change the version!", "version": "42.1337.0" }
- posharma 5y ago
  I've heard and read this multiple times. Why are you trying so hard to fit into a format that doesn't just support comments out of the box? What advantages is JSON offering you that you've compelled to bend over backwards to do this? It's exactly these kinds of workarounds that is making it super difficult stop such malpractices. It's just plain ugly. Please stop doing this.
  - cbm-vic-20 5y ago
    In many cases, you're using a library or service that you don't maintain, so you don't have much of a choice.
- justinpombrio 5y ago
  There's a lot of JSON tooling, and it's liable to interact badly with this. For example, a formatter might re-order the fields of a dict, moving "#comment-1" away from "version". Or the software that this JSON is for might error upon receiving unexpected keys (which is actually useful behavior, as that would catch a typo in an optional field). Also, this doesn't let you put comments at the top of the file, or before a list item, or at the end of a line. If you're going to change your JSON tooling to handle comments of some kind, you might as well go all the way to JSONC.
- argomo 5y ago
  You can't comment out a large section of config easily. For me, this is a relatively common use case for config files, so I take the position that JSON should be used for serialization only.
jackjeff 5y ago
JSONC. JSON with comments. And even if your favorite parser does not support it natively it’s not so hard to add with a very simple pre-lexer step. JSON schemas exist and they’re ok for relatively simple things. For more complex cases I find myself wishing I could just turn Typescript into some kind of schema validation for JSON.
- jestar_jokin 5y ago
  There's libraries that let you define a schema programmatically, and then infer the types. https://github.com/sinclairzx81/typebox https://github.com/sinclairzx81/typebox
- yesbabyyes 5y ago
  > For more complex cases I find myself wishing I could just turn Typescript into some kind of schema validation for JSON. Not sure if this is what you're looking for, and whether it's powerful and expressive enough for your use case, but you can use typescript-json-schema¹ for this, and validate with eg ajv. ¹https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema
- andyfleming 5y ago
  I like JSON5 for similar reasons. I specifically like the addition of comments, trailing commas, and keys without quotes.
  - silon42 5y ago
    Also needed is string concatenation. One line strings are very limiting.
  - eitland 5y ago
    I've struggled with this in Java recently and at first I used Jankson which supports the complete JSON5 spec, but later we figured out we could configure the standard Jackson JSON package to accept the things we actually need and actually use.
afavour 5y ago
JSON Schema is an official thing that exists and has implementations in all major languages. Personally I’m very glad that it’s an opt-in addition rather than a requirement. (I agree with you about comments though)
- fastball 5y ago
  For comments just use JSONC.
matja 5y ago
Seems to me that YAML just needs type/schema support to be less of a hurdle. As an alternative, the encoding/decoding roundtrip using protobuf seems reasonable to me, catches the footgun of using floating-point version numbers (it becomes a parse error), whitespace/multiline concatenation being more obvious, and allowing comments (compared to JSON): ( cat << EOF # yes, comments are allowed name: "Python package" on: "push" build { python_version: ["3.6", "3.7", "3.8", "3.9", "3.10"] steps: [ { name: "Install dependencies" run: "python -m pip install --upgrade pip\n" "pip install pytest\n" "if [ -f 'requirements.txt' ]; then pip install -r requirements.txt; fi\n" }, { name: "Test with pytest" run: "pytest\n" } ] } EOF ) | protoc --encode=Config config.proto | protoc --decode=Config config.proto name: "Python package" on: "push" build { python_version: "3.6" python_version: "3.7" python_version: "3.8" python_version: "3.9" python_version: "3.10" steps { name: "Install dependencies" run: "python -m pip install --upgrade pip\npip install pytest\nif [ -f \'requirements.txt\' ]; then pip install -r requirements.txt; fi\n" } steps { name: "Test with pytest" run: "pytest\n" } }
- elurg 5y ago
  > Seems to me that YAML just needs type/schema support to be less of a hurdle. JSON schemas exist and can be applied to yaml and this is supported by many editors. For example this vscode extension: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml https://marketplace.visualstudio.com/items?itemName=redhat.v... It's strange to see so many complains about "missing tooling" that actually exists and is well supported.
- rurban 5y ago
  > Seems to me that YAML just needs type/schema support to be less of a hurdle. Unfortunately YAML already got type support, which made it easier to roundtrip, but also insecure. Creating a type calls constructors with possible insecure side effects. Which was eg used to hack Movable Type.
IshKebab 5y ago
I agree, but I would recommend JSON5 as the solution. Not YAML or this abomination. JSON5 has many advantages: * Superset of JSON without being wildly different. I know YAML is a superset of JSON but it's completely different too. Insane. * Unambiguous grammar. YAML has way too many big structure decisions that are made by unclear and minor formatting differences. My work's YAML data is full of single-element lists that shouldn't be lists for example. * Comments, trailing commas * It's a subset of Javascript so basically nothing new to learn. * It has an unambiguous extension (.json5). I think JSONC would be a reasonable option but everyone uses the same extension as JSON (.json) so you can never be sure which you are using. E.g. `tsconfig.json` is JSONC but `package.json` is just JSON (to everyone's annoyance). * Doesn't add too much of Javascript. I wouldn't recommend JSON6 because it's just making the format too complicated for little benefit.
- rk06 5y ago
  I would rather recommend jsonc: - it has good editor support (VsCode) - has comments support - Support jsonschema Only thing missing is trailing commas, but i would rather live without trailing commas than tooling support
  - IshKebab 5y ago
    JSONC supports trailing commas. > - it has good editor support (VsCode) Unfortunately it doesn't really because of the extension issue I mentioned. Certain file names (like `tsconfig.json`) are whitelisted to have JSONC support, but any random file `foo.json` will be treated as JSON and give you annoying lints if you put comments and trailing commas in. That's a fairly recent change I think.
deleted 5y ago
[deleted]
benibela 5y ago
And I am just writing a JSON de/serializer to move my config from the current system to JSON. I worked on it today and yesterday and several days some time ago. This situation makes me feel rather silly

umvi 5y ago

So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day (and it doesn't have to be comment-less... JSON with comments is a thing and VSCode has syntax highlighting for it - just strip out the comments before parsing).

posharma 5y ago
It's simple. For config files, choose the format that has the best tooling in your company and that supports comments. For data transfer, choose that supports schemas, backwards compatibility and good tooling (protobufs is just one e.g. that I'm most familiar with).
stavros 5y ago
> So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Aren't we past basic false dichotomies?
- saurik 5y ago
  Nope: basic false dichotomies and JSON are both pervasive.
  - a9h74j 5y ago
    There is a corporate- and government-approved standard for false dichotomies, but it works as a de-facto standard, not published.
    - psd1 5y ago
      ifnot: - foo then_clearly: - 'some bar'
deleted 5y ago
[deleted]
zz865 5y ago
XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.
- nsonha 5y ago
  not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.
  - KronisLV 5y ago
    > It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).
donmcronald 5y ago
For me XML and YAML are about the same. I think I'd also prefer comment-less JSON over both. However, XML wasn't that bad. With a decent editor and schema validation I would say there's a good chance I was more productive with XML than I am with YAML.
mindcrime 5y ago
So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Sure, why not? XML rocks. I'll take it over JSON for many purposes.
int_19h 5y ago
Actually, yes, I do. XML syntax was far from stellar, and much of the ecosystem (e.g. XML Schema) was drastically overengineered... but even so, we had gems like RELAX NG to compensate. On the whole, it was better than the current mess.

runarberg 5y ago

Tools that use JSON as configuration format could simply allow certain unused keys (e.g. all keys starting with #) and promise never to use them. Then author can write their comments with something like: { "name": "my-tool", "#comment-1": "Don’t change the version!", "version": "42.1337.0" }

posharma 5y ago
I've heard and read this multiple times. Why are you trying so hard to fit into a format that doesn't just support comments out of the box? What advantages is JSON offering you that you've compelled to bend over backwards to do this? It's exactly these kinds of workarounds that is making it super difficult stop such malpractices. It's just plain ugly. Please stop doing this.
- cbm-vic-20 5y ago
  In many cases, you're using a library or service that you don't maintain, so you don't have much of a choice.
justinpombrio 5y ago
There's a lot of JSON tooling, and it's liable to interact badly with this. For example, a formatter might re-order the fields of a dict, moving "#comment-1" away from "version". Or the software that this JSON is for might error upon receiving unexpected keys (which is actually useful behavior, as that would catch a typo in an optional field). Also, this doesn't let you put comments at the top of the file, or before a list item, or at the end of a line. If you're going to change your JSON tooling to handle comments of some kind, you might as well go all the way to JSONC.
argomo 5y ago
You can't comment out a large section of config easily. For me, this is a relatively common use case for config files, so I take the position that JSON should be used for serialization only.

jackjeff 5y ago

JSONC. JSON with comments. And even if your favorite parser does not support it natively it’s not so hard to add with a very simple pre-lexer step. JSON schemas exist and they’re ok for relatively simple things. For more complex cases I find myself wishing I could just turn Typescript into some kind of schema validation for JSON.

jestar_jokin 5y ago
There's libraries that let you define a schema programmatically, and then infer the types. https://github.com/sinclairzx81/typebox https://github.com/sinclairzx81/typebox
yesbabyyes 5y ago
> For more complex cases I find myself wishing I could just turn Typescript into some kind of schema validation for JSON. Not sure if this is what you're looking for, and whether it's powerful and expressive enough for your use case, but you can use typescript-json-schema¹ for this, and validate with eg ajv. ¹https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema
andyfleming 5y ago
I like JSON5 for similar reasons. I specifically like the addition of comments, trailing commas, and keys without quotes.
- silon42 5y ago
  Also needed is string concatenation. One line strings are very limiting.
- eitland 5y ago
  I've struggled with this in Java recently and at first I used Jankson which supports the complete JSON5 spec, but later we figured out we could configure the standard Jackson JSON package to accept the things we actually need and actually use.

afavour 5y ago

JSON Schema is an official thing that exists and has implementations in all major languages. Personally I’m very glad that it’s an opt-in addition rather than a requirement. (I agree with you about comments though)

fastball 5y ago
For comments just use JSONC.

matja 5y ago

Seems to me that YAML just needs type/schema support to be less of a hurdle. As an alternative, the encoding/decoding roundtrip using protobuf seems reasonable to me, catches the footgun of using floating-point version numbers (it becomes a parse error), whitespace/multiline concatenation being more obvious, and allowing comments (compared to JSON): ( cat << EOF # yes, comments are allowed name: "Python package" on: "push" build { python_version: ["3.6", "3.7", "3.8", "3.9", "3.10"] steps: [ { name: "Install dependencies" run: "python -m pip install --upgrade pip\n" "pip install pytest\n" "if [ -f 'requirements.txt' ]; then pip install -r requirements.txt; fi\n" }, { name: "Test with pytest" run: "pytest\n" } ] } EOF ) | protoc --encode=Config config.proto | protoc --decode=Config config.proto name: "Python package" on: "push" build { python_version: "3.6" python_version: "3.7" python_version: "3.8" python_version: "3.9" python_version: "3.10" steps { name: "Install dependencies" run: "python -m pip install --upgrade pip\npip install pytest\nif [ -f \'requirements.txt\' ]; then pip install -r requirements.txt; fi\n" } steps { name: "Test with pytest" run: "pytest\n" } }

elurg 5y ago
> Seems to me that YAML just needs type/schema support to be less of a hurdle. JSON schemas exist and can be applied to yaml and this is supported by many editors. For example this vscode extension: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml https://marketplace.visualstudio.com/items?itemName=redhat.v... It's strange to see so many complains about "missing tooling" that actually exists and is well supported.
rurban 5y ago
> Seems to me that YAML just needs type/schema support to be less of a hurdle. Unfortunately YAML already got type support, which made it easier to roundtrip, but also insecure. Creating a type calls constructors with possible insecure side effects. Which was eg used to hack Movable Type.

IshKebab 5y ago

I agree, but I would recommend JSON5 as the solution. Not YAML or this abomination. JSON5 has many advantages: * Superset of JSON without being wildly different. I know YAML is a superset of JSON but it's completely different too. Insane. * Unambiguous grammar. YAML has way too many big structure decisions that are made by unclear and minor formatting differences. My work's YAML data is full of single-element lists that shouldn't be lists for example. * Comments, trailing commas * It's a subset of Javascript so basically nothing new to learn. * It has an unambiguous extension (.json5). I think JSONC would be a reasonable option but everyone uses the same extension as JSON (.json) so you can never be sure which you are using. E.g. `tsconfig.json` is JSONC but `package.json` is just JSON (to everyone's annoyance). * Doesn't add too much of Javascript. I wouldn't recommend JSON6 because it's just making the format too complicated for little benefit.

rk06 5y ago
I would rather recommend jsonc: - it has good editor support (VsCode) - has comments support - Support jsonschema Only thing missing is trailing commas, but i would rather live without trailing commas than tooling support
- IshKebab 5y ago
  JSONC supports trailing commas. > - it has good editor support (VsCode) Unfortunately it doesn't really because of the extension issue I mentioned. Certain file names (like `tsconfig.json`) are whitelisted to have JSONC support, but any random file `foo.json` will be treated as JSON and give you annoying lints if you put comments and trailing commas in. That's a fairly recent change I think.

deleted 5y ago

[deleted]

benibela 5y ago

And I am just writing a JSON de/serializer to move my config from the current system to JSON. I worked on it today and yesterday and several days some time ago. This situation makes me feel rather silly