5 ms·

JSON is one of the most iconic tragedies that happened in software development. It's not that JSON itself is bad, but it's obviously for machines to author, no

JSON is one of the most iconic tragedies that happened in software development. It's not that JSON itself is bad, but it's obviously for machines to author, not for humans. - No comment - No trailing comma - No multi-line string It's a terrible format to type manually. However, we just shrugged and said "at least it's not XML" and started writing it manually anyway. And later we finally realized comments are not optional, so we got JSON5, JSONC, etc...

eviks 1y ago
> And later we finally realized comments are not optional, so we got JSON5, JSONC, etc... But we haven't, otherwise we'd use all those better formats instead
s1mplicissimus 1y ago
> And later we finally realized comments are not optional except they very much are. the place to explain your payload is in the API documentation, not alongside the payload. It's not code.
- nwellinghoff 1y ago
  What about json schema files? Hmmm
- rkomorn 1y ago
  That kind of stops working when (for example) your "payload" is configuration in a file where comments may make sense, though. I'm more partial to YAML for readability, but I don't think JSON configs are an awful anti pattern.
- raincole 1y ago
  The exact issue is that JSON's usage spread far beyond "payload." > It's not code. package.json has a field literally called 'scripts' where the values are shell one-liners.
- tedggh 1y ago
  This is true, but it is also true that if someone who didn’t read the documentation or the latest version of it, changes a config parameter that brings down a critical system you are responsible for, your bosses or customers won’t care if it was in the documentation or not.
- slowmovintarget 1y ago
  Confused puppy look https://orgmode.org/worg/org-contrib/babel/ https://orgmode.org/worg/org-contrib/babel/
- illuminator83 1y ago
  When you are commenting your schema, that's true. Anything which is generated by machines doesn't need comments either. But when it's written by people? And the values? That belongs with the 'payload'.
theshrike79 1y ago
And we have XML. JSON is rediscovering XML Schema, XML DTDs etc, when we had those a quarter century ago already. It was so good when you could define the structure easily and validate it with standard tooling.
- ninkendo 1y ago
  The problem I always had with XML is that it's not clear how to properly encode typical data. If I have a structure like this JSON: { "foo": "bar", "nested": { "nested_foo": "nested_bar", } } Should I do this in XML? <foo> bar </foo> <nested> <nested_foo> nested_bar </nested_foo> </nested> Or should I do this? <foo> bar </foo> <nested nested_foo="nested_bar"/> If your goal is to simply encode a data structure that looks more or less like a C-style struct (key/values, arrays, primitives), the concept of attributes on tags is superfluous, and introduces ambiguity in how to serialize something. To me, JSON is nice because it's essentially the minimum viable way of encoding a C-style struct (floating point behavior notwithstanding.) XML has extras like attributes, schemas, and DTDs, which may be useful, but they come at the cost of having additional syntax (<!DOCTYPE ...>, etc), which is auxiliary to the goal of encoding data structures, and thus makes it no longer as minimal. To me, JSON's approach of having a separate out-of-band definitions of schema (e.g. JSON schema) is the better approach because it's less opinionated, you only pay for it when you need it, and it doesn't require separate syntax. Leave validation to a validation step, my data is my data.
  - wpm 1y ago
    I work with an API that returns XML that uses zero tag attributes. It’s all just tags, nested. It’s actually a joy to work with. I see some XML from other sources and it’s just awful. Everything that should be a nested tag is all jammed into an unreadable tag with attributes with no visual structure at all, spilling over the 80th column and word-wrapping in the terminal, it’s just like, what the hell. Why even use XML at that point?
  - theshrike79 1y ago
    The first one. Where you'd do attributes is like this: <foo type="address"> bar </foo> <nested type="resident_list"> <nested_foo type="resident"> nested_bar </nested_foo> </nested> A shitty example (you'd define types with schema), but you get the point. The data is in the tags, attributes are metadata, extra information that's needed during the process. This is what JSON is lacking, you can't give metadata to data, like defining types. The type definition needs to live NEXT to the data in special keys you need to check every time when parsing.
Cthulhu_ 1y ago
I agree that it's a tragedy, XML had so much standardization, tooling, validation, etc available, it was great. But people used it for configuration and manually writing it, which sucked. 15 years later and JSON still is still very far from the standardization and tooling that XML had at the time. It reminds me of the NoSQL thing from back then too, oversimplified it was "what if we chuck JSON blobs in a key/value store?". It took years to realize that relational databases and SQL weren't actually that bad, and / or that NoSQL had a long term cost.
- whizzter 1y ago
  And that was the downfall.. 1: Standardization was made by committee lovers and/or architecture astronauts leaving us with overly convoluted (sometimes to fit lacklustre object models in early OO languages) and complex ways of working. 2: Complexity that introduced security vulnerabilities Sure, there was some great tooling available, but how much of it was needed because all complexity made it hopeless to work with without the tooling? I used it for configuration and serialization in some projects, and it was actually great but I almost always diverged from the bloated norms and defaults for readability/writeability (that made it a bit annoying to specify serialization rules). I mean, why did people prefer? <object><property name="somename"><int32>123</int32></property></object> Over just? <object somename="123"/> Yeah there is so much "flexibility" in those above designs but it wasn't needed 99% of the time. JSON was and is so far the best popular compromise between "just plain data" and "some" structure to make automated processing non-painful. Also as an improvement over XML collections (do you created a container element to specify container target leading to bloat or just map some of the sub-elements to specific collections and hope you don't run into ambiguities?) is that collections are just specific lists to a property. The biggest drawback of JSON is that we never had a way to handle type specializations/subtyping but had we done that we might have not gotten the universal acceptance across languages. Yes, comments but whenever you need that you can make a single-line regexp to strip a useful subset of them without affecting anything by the standard by removing matches of /^\s*\/\/[^\r\n]*/mg
- BobbyTables2 1y ago
  Fortunately we learned our lesson with YAML. (/s) Easier to write than JSON. But weirdly harder to get right in other ways, especially for nesting things. Almost made the mistake of becoming simple to parse. Alas, defeat was again snatched from the jaws of victory on that one…
pavel_lishin 1y ago
Still better than YAML.
TZubiri 1y ago
"I use JSON for just about every data file format in my games." Not to be mean, but this has the trifecta of amateur programming: - JSON - Games - One solution for everything. Pro tip, you can store variables as they are in memory to disk. Got 1 million 2D points representing units? Each point is a couple of floats? You can store each float as-is, write the amount of floats as an int (4bytes), the first float is the X coord, the second the Y coord, (4 bytes each), then repeat 1M times, boom you just solved that in 8MB, and in a couple of miliseconds of compute. Bonus point, no escaping, no import json, just a programmer programming.
- dxdm 1y ago
  > Not to be mean, but this has the trifecta of amateur programming But you are being mean. Also, the guy who wrote the article is no amateur, but a seasoned veteran who's likely been storing floats in files for decades. Check him out, you might be surprised. https://www.grumpygamer.com/about/ https://www.grumpygamer.com/about/
  - TZubiri 1y ago
    I recant. Programmers who had to do low level programming due to early hardware restrictions are hereby granted immunity from high-level elitism and gatekeeping, they can vibe code and npm install is-even if they so wish to.
sorrynorry22 1y ago
[dead]
est 1y ago
> No multi-line string Which is a good thing. This makes JSONL possible.
- yencabulator 1y ago
  Yes, that's clearly why this is also an invalid JSON document: { "uhh": "nope" } JSONL would just dictate that string values must not be in the multi-line form.

eviks 1y ago

> And later we finally realized comments are not optional, so we got JSON5, JSONC, etc... But we haven't, otherwise we'd use all those better formats instead

s1mplicissimus 1y ago

> And later we finally realized comments are not optional except they very much are. the place to explain your payload is in the API documentation, not alongside the payload. It's not code.

nwellinghoff 1y ago
What about json schema files? Hmmm
rkomorn 1y ago
That kind of stops working when (for example) your "payload" is configuration in a file where comments may make sense, though. I'm more partial to YAML for readability, but I don't think JSON configs are an awful anti pattern.
raincole 1y ago
The exact issue is that JSON's usage spread far beyond "payload." > It's not code. package.json has a field literally called 'scripts' where the values are shell one-liners.
tedggh 1y ago
This is true, but it is also true that if someone who didn’t read the documentation or the latest version of it, changes a config parameter that brings down a critical system you are responsible for, your bosses or customers won’t care if it was in the documentation or not.
slowmovintarget 1y ago
Confused puppy look https://orgmode.org/worg/org-contrib/babel/ https://orgmode.org/worg/org-contrib/babel/
illuminator83 1y ago
When you are commenting your schema, that's true. Anything which is generated by machines doesn't need comments either. But when it's written by people? And the values? That belongs with the 'payload'.

theshrike79 1y ago

And we have XML. JSON is rediscovering XML Schema, XML DTDs etc, when we had those a quarter century ago already. It was so good when you could define the structure easily and validate it with standard tooling.

ninkendo 1y ago
The problem I always had with XML is that it's not clear how to properly encode typical data. If I have a structure like this JSON: { "foo": "bar", "nested": { "nested_foo": "nested_bar", } } Should I do this in XML? <foo> bar </foo> <nested> <nested_foo> nested_bar </nested_foo> </nested> Or should I do this? <foo> bar </foo> <nested nested_foo="nested_bar"/> If your goal is to simply encode a data structure that looks more or less like a C-style struct (key/values, arrays, primitives), the concept of attributes on tags is superfluous, and introduces ambiguity in how to serialize something. To me, JSON is nice because it's essentially the minimum viable way of encoding a C-style struct (floating point behavior notwithstanding.) XML has extras like attributes, schemas, and DTDs, which may be useful, but they come at the cost of having additional syntax (<!DOCTYPE ...>, etc), which is auxiliary to the goal of encoding data structures, and thus makes it no longer as minimal. To me, JSON's approach of having a separate out-of-band definitions of schema (e.g. JSON schema) is the better approach because it's less opinionated, you only pay for it when you need it, and it doesn't require separate syntax. Leave validation to a validation step, my data is my data.
- wpm 1y ago
  I work with an API that returns XML that uses zero tag attributes. It’s all just tags, nested. It’s actually a joy to work with. I see some XML from other sources and it’s just awful. Everything that should be a nested tag is all jammed into an unreadable tag with attributes with no visual structure at all, spilling over the 80th column and word-wrapping in the terminal, it’s just like, what the hell. Why even use XML at that point?
- theshrike79 1y ago
  The first one. Where you'd do attributes is like this: <foo type="address"> bar </foo> <nested type="resident_list"> <nested_foo type="resident"> nested_bar </nested_foo> </nested> A shitty example (you'd define types with schema), but you get the point. The data is in the tags, attributes are metadata, extra information that's needed during the process. This is what JSON is lacking, you can't give metadata to data, like defining types. The type definition needs to live NEXT to the data in special keys you need to check every time when parsing.

Cthulhu_ 1y ago

I agree that it's a tragedy, XML had so much standardization, tooling, validation, etc available, it was great. But people used it for configuration and manually writing it, which sucked. 15 years later and JSON still is still very far from the standardization and tooling that XML had at the time. It reminds me of the NoSQL thing from back then too, oversimplified it was "what if we chuck JSON blobs in a key/value store?". It took years to realize that relational databases and SQL weren't actually that bad, and / or that NoSQL had a long term cost.

whizzter 1y ago
And that was the downfall.. 1: Standardization was made by committee lovers and/or architecture astronauts leaving us with overly convoluted (sometimes to fit lacklustre object models in early OO languages) and complex ways of working. 2: Complexity that introduced security vulnerabilities Sure, there was some great tooling available, but how much of it was needed because all complexity made it hopeless to work with without the tooling? I used it for configuration and serialization in some projects, and it was actually great but I almost always diverged from the bloated norms and defaults for readability/writeability (that made it a bit annoying to specify serialization rules). I mean, why did people prefer? <object><property name="somename"><int32>123</int32></property></object> Over just? <object somename="123"/> Yeah there is so much "flexibility" in those above designs but it wasn't needed 99% of the time. JSON was and is so far the best popular compromise between "just plain data" and "some" structure to make automated processing non-painful. Also as an improvement over XML collections (do you created a container element to specify container target leading to bloat or just map some of the sub-elements to specific collections and hope you don't run into ambiguities?) is that collections are just specific lists to a property. The biggest drawback of JSON is that we never had a way to handle type specializations/subtyping but had we done that we might have not gotten the universal acceptance across languages. Yes, comments but whenever you need that you can make a single-line regexp to strip a useful subset of them without affecting anything by the standard by removing matches of /^\s*\/\/[^\r\n]*/mg
BobbyTables2 1y ago
Fortunately we learned our lesson with YAML. (/s) Easier to write than JSON. But weirdly harder to get right in other ways, especially for nesting things. Almost made the mistake of becoming simple to parse. Alas, defeat was again snatched from the jaws of victory on that one…

pavel_lishin 1y ago

Still better than YAML.

TZubiri 1y ago

"I use JSON for just about every data file format in my games." Not to be mean, but this has the trifecta of amateur programming: - JSON - Games - One solution for everything. Pro tip, you can store variables as they are in memory to disk. Got 1 million 2D points representing units? Each point is a couple of floats? You can store each float as-is, write the amount of floats as an int (4bytes), the first float is the X coord, the second the Y coord, (4 bytes each), then repeat 1M times, boom you just solved that in 8MB, and in a couple of miliseconds of compute. Bonus point, no escaping, no import json, just a programmer programming.

dxdm 1y ago
> Not to be mean, but this has the trifecta of amateur programming But you are being mean. Also, the guy who wrote the article is no amateur, but a seasoned veteran who's likely been storing floats in files for decades. Check him out, you might be surprised. https://www.grumpygamer.com/about/ https://www.grumpygamer.com/about/
- TZubiri 1y ago
  I recant. Programmers who had to do low level programming due to early hardware restrictions are hereby granted immunity from high-level elitism and gatekeeping, they can vibe code and npm install is-even if they so wish to.

sorrynorry22 1y ago

[dead]

est 1y ago

> No multi-line string Which is a good thing. This makes JSONL possible.

yencabulator 1y ago
Yes, that's clearly why this is also an invalid JSON document: { "uhh": "nope" } JSONL would just dictate that string values must not be in the multi-line form.