3 ms·

Msgpack and protobuf do that too. I believe the rise of JSON is attributed to that it's easily human-readable, and because Javascript.

lucideer 5y ago
Not sure human-readability was a major consideration of JSON really, but maybe. One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent comma-ing etc. In general giving the author less options will make your parser simpler. This is notably the exact opposite of YAML's approach. JSON5 is nowhere near as bad as YAML, but it does seem to leaving behind some of the raison d'être of JSON. Like, I hate double-quoting in JS/JSON (personal bike-shed colour preference), but surely variable quoting characters is the worst of both worlds.
- brundolf 5y ago
  Agreed. Every single feature here complicates parsing, and the only two that are worth it IMO are comments and multi-line strings (though I'm sure others disagree on which ones are most important, which is how we end up with something like this)
  - lucideer 5y ago
    Comments maybe. Multi-line strings though I don't really see as very valuable. Lack of multi-line strings in JS was a very large, but infrequent pain for years before it was added. That infrequency tends toward zero for JSON: most of it is generated, and even when it is hand-authored, long strings are very much an exception in those cases (in my experience).
    - brundolf 5y ago
      Two use-cases come to mind: a) Short series' of shell commands in package.json b) Longform content I disagree that JSON is rarely hand-authored. You could argue it isn't the best medium for these usecases, but it definitely gets used for them either way
      - lucideer 5y ago
        JSON is often hand-authored as small config formats (in which your use-case (a) is relevant*), but I have never seen it hand-authored for readable "content". Firstly longform content is often rich-text; if that's hand-authored in something that's not a wysiwyg UI, it's typically a dedicated separate file (.html or .md) which may-or-may not be later programmatically compiled to JSON. For longform content that's not rich-text, and doesn't warrant a separate dedicated .txt file: how long is it? Do you really need multiline strings? The only real use-case I've seen is i18n string map files, where some translations can contain a newline or two, but these are an exception; the majority of strings in those files are short. ---- * On use-case (a), this is a personal preference but I tend to prefer referencing single independent executables in these use-cases, to the modern trend of having long unreadable bash one-liners in config files.

lucideer 5y ago

Not sure human-readability was a major consideration of JSON really, but maybe. One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent comma-ing etc. In general giving the author less options will make your parser simpler. This is notably the exact opposite of YAML's approach. JSON5 is nowhere near as bad as YAML, but it does seem to leaving behind some of the raison d'être of JSON. Like, I hate double-quoting in JS/JSON (personal bike-shed colour preference), but surely variable quoting characters is the worst of both worlds.

brundolf 5y ago
Agreed. Every single feature here complicates parsing, and the only two that are worth it IMO are comments and multi-line strings (though I'm sure others disagree on which ones are most important, which is how we end up with something like this)
- lucideer 5y ago
  Comments maybe. Multi-line strings though I don't really see as very valuable. Lack of multi-line strings in JS was a very large, but infrequent pain for years before it was added. That infrequency tends toward zero for JSON: most of it is generated, and even when it is hand-authored, long strings are very much an exception in those cases (in my experience).
  - brundolf 5y ago
    Two use-cases come to mind: a) Short series' of shell commands in package.json b) Longform content I disagree that JSON is rarely hand-authored. You could argue it isn't the best medium for these usecases, but it definitely gets used for them either way
    - lucideer 5y ago
      JSON is often hand-authored as small config formats (in which your use-case (a) is relevant*), but I have never seen it hand-authored for readable "content". Firstly longform content is often rich-text; if that's hand-authored in something that's not a wysiwyg UI, it's typically a dedicated separate file (.html or .md) which may-or-may not be later programmatically compiled to JSON. For longform content that's not rich-text, and doesn't warrant a separate dedicated .txt file: how long is it? Do you really need multiline strings? The only real use-case I've seen is i18n string map files, where some translations can contain a newline or two, but these are an exception; the majority of strings in those files are short. ---- * On use-case (a), this is a personal preference but I tend to prefer referencing single independent executables in these use-cases, to the modern trend of having long unreadable bash one-liners in config files.