3 ms·

The argument against JSON isn't very compelling. Adding a name to every field as they do in their strawman example isn't necessary. Compare this CSV field

by hajile 2y ago

The argument against JSON isn't very compelling. Adding a name to every field as they do in their strawman example isn't necessary. Compare this CSV field1,field2,fieldN "value (0,0)","value (0,1)","value (0,n)" "value (1,0)","value (1,1)","value (1,n)" "value (2,0)","value (2,1)","value (2,n)" To the directly-equivalent JSON [["field1","field2","fieldN"], ["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","value (1,1)","value (1,n)"], ["value (2,0)","value (2,1)","value (2,n)"]] The JSON version is only marginally bigger (just a few brackets), but those brackets represent the ability to be either simple or complex. This matters because you wind up with terrible ad-hoc nesting in CSV ranging from entries using query string syntax to some entirely custom arrangement. person,val2,val3,valN fname=john&lname=doe&age=55&children=[jill|jim|joey],v2,v3,vN And in these cases, JSON's objects are WAY better. Because CSV is so simple, it's common for them to avoid using a parsing/encoding library. Over the years, I've run into this particular kind of issue a bunch. //outputs `val1,val2,unexpected,comma,valN` which has one too many items ["val1", "val2", "unexpected,comma", "valN"].join(',') JSON parsers will not only output the expected values every time, but your language likely uses one of the super-efficient SIMD-based parsers under the surface (probably faster than what you are doing with your custom CSV parser). Another point is standardization. Does that .csv file use commas, spaces, semicolons, pipes, etc? Does it use CR,LF, or CRLF? Does it allow escaping quotations? Does it allow quotations to escape commas? Is it utf-8, UCS-2, or something different? JSON doesn't have these issues because these are all laid out in the spec. JSON is typed. Sure, it's not a LOT of types, but 6 types is better than none. While JSON isn't perfect (I'd love to see an official updated spec with some additional features), it's generally better than CSV in my experience.

croes 2y ago
> Because CSV is so simple, it's common for them to avoid using a parsing/encoding library. A but unfair to compare CSV without parser library to JSON with library.
- hajile 2y ago
  Essentially nobody uses JSON without a library, but tons of people (maybe even most people) use CSV without a library. Part of the problem here is standards. There's a TON of encoding variations all using the same .csv extension. Making a library that can accurately detect exactly which one is correct is a big problem once you leave the handful of most common variants. If you are doing subfield encoding, you are almost certainly on your own with decoding at least part of your system. JSON has just one standard and everyone adheres to that standard which makes fast libraries possible.
pphysch 2y ago
The flexibility of JSON is a downside when you just want to stream large volumes of row-oriented tabular data
- hajile 2y ago
  If you want to stream large volumes of row-oriented data, you aren't reading yourself and you should be using a binary format which is going to be significantly smaller (especially for numeric data).
  - pphysch 2y ago
    Yeah that would be the next step in optimization. In the meanwhile, raw text CSV streaming (for not purely numeric data) is still extremely fast and easy to set up
munchler 2y ago
> the directly-equivalent JSON [["field1","field2","fieldN"], ["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","value (1,1)","value (1,n)"], ["value (2,0)","value (2,1)","value (2,n)"]] I think it's a big stretch to use that JSON for comparison. In practice, one is much more likely to see this: [ { "field1": "value (0,0)", "field2": "value (0,1)", "fieldN": "value (0,n)" }, { "field1": "value (1,0)", "field2": "value (1,1)", "fieldN": "value (1,n)" }, { "field1": "value (2,0)", "field2": "value (2,1)", "fieldN": "value (2,n)" } ]
- hajile 2y ago
  While most people would prefer the second version, the first version is also valid JSON and will definitely see use when you want/need JSON but want to reduce data over the wire though you'd probably still see a wrapper object like: { headers: ["field1","field2","fieldN"], values: [["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","value (1,1)","value (1,n)"], ["value (2,0)","value (2,1)","value (2,n)"]] }
bobmcnamara 2y ago
> JSON parsers will not only output the expected values every time Unless you need appendability, but then you should probably just use NDJSON/JSONL for a lot of cases.

by hajile 2y ago

croes 2y ago

> Because CSV is so simple, it's common for them to avoid using a parsing/encoding library. A but unfair to compare CSV without parser library to JSON with library.

hajile 2y ago
Essentially nobody uses JSON without a library, but tons of people (maybe even most people) use CSV without a library. Part of the problem here is standards. There's a TON of encoding variations all using the same .csv extension. Making a library that can accurately detect exactly which one is correct is a big problem once you leave the handful of most common variants. If you are doing subfield encoding, you are almost certainly on your own with decoding at least part of your system. JSON has just one standard and everyone adheres to that standard which makes fast libraries possible.

pphysch 2y ago

The flexibility of JSON is a downside when you just want to stream large volumes of row-oriented tabular data

hajile 2y ago
If you want to stream large volumes of row-oriented data, you aren't reading yourself and you should be using a binary format which is going to be significantly smaller (especially for numeric data).
- pphysch 2y ago
  Yeah that would be the next step in optimization. In the meanwhile, raw text CSV streaming (for not purely numeric data) is still extremely fast and easy to set up

munchler 2y ago

> the directly-equivalent JSON [["field1","field2","fieldN"], ["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","value (1,1)","value (1,n)"], ["value (2,0)","value (2,1)","value (2,n)"]] I think it's a big stretch to use that JSON for comparison. In practice, one is much more likely to see this: [ { "field1": "value (0,0)", "field2": "value (0,1)", "fieldN": "value (0,n)" }, { "field1": "value (1,0)", "field2": "value (1,1)", "fieldN": "value (1,n)" }, { "field1": "value (2,0)", "field2": "value (2,1)", "fieldN": "value (2,n)" } ]

hajile 2y ago
While most people would prefer the second version, the first version is also valid JSON and will definitely see use when you want/need JSON but want to reduce data over the wire though you'd probably still see a wrapper object like: { headers: ["field1","field2","fieldN"], values: [["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","value (1,1)","value (1,n)"], ["value (2,0)","value (2,1)","value (2,n)"]] }

bobmcnamara 2y ago

> JSON parsers will not only output the expected values every time Unless you need appendability, but then you should probably just use NDJSON/JSONL for a lot of cases.