6 ms·

The first thing I see when I go to the site: JSON SUCKS Uh... It does? I remember when XML was the main data interchange format of the web. That sucked. JSON i

The first thing I see when I go to the site: JSON SUCKS Uh... It does? I remember when XML was the main data interchange format of the web. That sucked. JSON is amazing, terrific, wonderful, etc. in comparison.

stevoski 4y ago
Indeed. I’m (sorta) old and cranky and even I love JSON as a data interchange format. Because I had to use XML for years, including SOAP.
998244353 4y ago
It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON.
- eru 4y ago
  We had S-Expressions before we had JSON. (And JavaScript originally wanted to be a Lisp, too.) It's not that we had XML and SGML and XDR because nobody had invented something as simple as JSON, yet. The real reasons are some complicated social hodgepodge that made those complicated beasts more accepted than the already-invented simpler approaches.
- s3000 4y ago
  Why does React use JSX when it could be all JavaScript and JSON? My guess is that XML is good for situations where text and data is mixed.
  - kaoD 4y ago
    Named closing tags are good when manually writing stuff because it reduces the opportunity for errors.
    - alpaca128 4y ago
      What advantage does that have compared to simple bracket highlighting and indentation? Editors can easily highlight mismatched parentheses, they are however rarely smart enough to auto-close XML tag pairs. I just see it as unnecessary clutter. Meanwhile the only issue I have with JSON is the lack of support for trailing commas.
      - postalrat 4y ago
        Named closing tags are another confirmation when inserting stuff at the end. I think multiple different confirmations can be easier to recognize than a single one.
  - 8n4vidtmkvmk 4y ago
    because separating attributes and child elements is actually useful in that context. better matches the Dom. and we need the power of js to do stuffs.
  - simplotek 4y ago
    > My guess is that XML is good for situations where text and data is mixed. I don't agree. My take is that HTML/XML-like syntaxes benefit from familiarity from front-end developers, and a DSL to express document/component trees ends up simplifying the job of expressing document/component trees.
    - postalrat 4y ago
      "a DSL"... like HTML? Or do you have one in mind you feel is better.
- simplotek 4y ago
  > It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON. It's my understanding that JSON was not invented. It's just the necessary and sufficient parts of JavaScript to define data structures, and could be parsed/imported in a browser with a call to eval(). People who complain about JSON completely miss the whole point. It's not that it's great or trouble-free, it's that it solved the need to exchange data with a browser without requiring any library or framework.
  - irrational 4y ago
    I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford. Before he invented JSON, we used XML to pass data around the web. After he invented JSON, it took quite awhile to catch on. There were many years of transition where some web services would only send xml and others could send xml or json. Eventually all web services gave you the choice of which one it would send. And then, gradually, xml was transitioned out and everything was json.
    - simplotek 4y ago
      > I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford. Douglas Crockford took his time to write up a specification for the JavaScript Object Notation (JSON). That specification is, quite literally, "based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999." It's in the name. There is no way around this. MDN's doc on JavaScript's eval() vs JSON.parse() refer to JSON as "a subset of JavaScript syntax to represent data." Claiming that someone discovered JSON makes as much sense as reading the C standard section on struct initialization and proceed to claim you discovered the C struct notation (CSN). https://en.cppreference.com/w/c/language/struct_initialization https://en.cppreference.com/w/c/language/struct_initializati...
      - irrational 4y ago
        I don’t think that means it was not invented. Otherwise we would have had it years before. What I understand “based on a subset of JavaScript” to mean is, Crockford chose some of the JS data types (object, array, number, string) and invented a string representation of them that could be used as a data interchange format. That was revolutionary. I remember when I first learned about JSON. It felt like Crockford was a genius for coming up with it, and then wondering why nobody else had come up with it before him. There is no way we would have suffered through XML Hell for so many years I’d there had been another option. But there wasn’t another option. Why? Because Crockford hadn’t invented JSON yet.
eallam 4y ago
Yea I really wanted to write "JSON is worse is better" because JSON is great and simple. We really just mean "reading complicated JSON files sucks"
- paco3346 4y ago
  So why not say that? When I see a tool or service make a claim as simple as "JSON SUCKS" it makes me think I'm not the target audience. I can read a 10 like file without a parser. What I don't like is 7 layers deep, nested, 890 lines long.
KronisLV 4y ago
> I remember when XML was the main data interchange format of the web. That sucked. I wonder why - apart from the "Should this be an element or an attribute?" issues and oddities in various implementations, XML doesn't seem like the worst thing ever. Actually, in a web development context, I'd argue that WSDL that was used with SOAP was superior to how most people worked with REST (and how some do), since it's taken OpenAPI years to catch up and codegen is still not quite as widespread, despite notable progress: https://openapi-generator.tech/ https://openapi-generator.tech/ What does leave a sour taste, however, is the fact that configuration turned into XML hell (not in a web context, but for apps locally) much like we have YAML hell nowadays, as well as people being able to focus on codegen absolved them of the need to pay lots of attention towards how intuitive their data structures are. That said, JSON also seems okay and it being simpler is a good thing. Though personally JSON5 feels like it addresses a few things that some might find missing: https://json5.org/ https://json5.org/ (despite it being a non-starter for many, due to limited popularity/support)
- irrational 4y ago
  For me, it is because I can do JSON.parse() and boom, it is plain JavaScript objects, arrays, strings, etc. XML was never that simple.
  - mdaniel 4y ago
    That's actually a good observation, and one I hadn't previously considered The trade-off of "that simple" is now every JSON tool has to reinvent XML-RPC, XPath, XML Schema, etc. In that way, JSON may be following the path of every other JS thing: arg, this framework is too heavy, I'm going to write a lighter one! ... ok, just with this one other feature .. ok, and this one ... arg, this framework is too heavy!
- orthoxerox 4y ago
  Namespaces. I know why they were introduced, but they still were an incredible pain to use, especially with SOAP. You want to pass a <Customer> to the update method? No, it must be <Customer xmlns="http://example.com/api/customers/v2 http://example.com/api/customers/v2"> that is wrapped in a <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope">. Oh, you're writing a service? You can't just XPath your way to that <Customer>, because it's a namespaced <Customer>, your XML parser will claim there's no <Customer> in the message, you have to register your namespaces "http://example.com/api/customers/v2 http://example.com/api/customers/v2" and "http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope" and look for /soap:Envelope/soap:Body/c:Customer instead. JSON is annoyingly anal about its commas, but at least it has a single global namespace and I have never encountered a situation where I wished I could disambiguate between two different "customer" objects in my JSON payload.

stevoski 4y ago

Indeed. I’m (sorta) old and cranky and even I love JSON as a data interchange format. Because I had to use XML for years, including SOAP.

998244353 4y ago

It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON.

eru 4y ago
We had S-Expressions before we had JSON. (And JavaScript originally wanted to be a Lisp, too.) It's not that we had XML and SGML and XDR because nobody had invented something as simple as JSON, yet. The real reasons are some complicated social hodgepodge that made those complicated beasts more accepted than the already-invented simpler approaches.
s3000 4y ago
Why does React use JSX when it could be all JavaScript and JSON? My guess is that XML is good for situations where text and data is mixed.
- kaoD 4y ago
  Named closing tags are good when manually writing stuff because it reduces the opportunity for errors.
  - alpaca128 4y ago
    What advantage does that have compared to simple bracket highlighting and indentation? Editors can easily highlight mismatched parentheses, they are however rarely smart enough to auto-close XML tag pairs. I just see it as unnecessary clutter. Meanwhile the only issue I have with JSON is the lack of support for trailing commas.
    - postalrat 4y ago
      Named closing tags are another confirmation when inserting stuff at the end. I think multiple different confirmations can be easier to recognize than a single one.
- 8n4vidtmkvmk 4y ago
  because separating attributes and child elements is actually useful in that context. better matches the Dom. and we need the power of js to do stuffs.
- simplotek 4y ago
  > My guess is that XML is good for situations where text and data is mixed. I don't agree. My take is that HTML/XML-like syntaxes benefit from familiarity from front-end developers, and a DSL to express document/component trees ends up simplifying the job of expressing document/component trees.
  - postalrat 4y ago
    "a DSL"... like HTML? Or do you have one in mind you feel is better.
simplotek 4y ago
> It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON. It's my understanding that JSON was not invented. It's just the necessary and sufficient parts of JavaScript to define data structures, and could be parsed/imported in a browser with a call to eval(). People who complain about JSON completely miss the whole point. It's not that it's great or trouble-free, it's that it solved the need to exchange data with a browser without requiring any library or framework.
- irrational 4y ago
  I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford. Before he invented JSON, we used XML to pass data around the web. After he invented JSON, it took quite awhile to catch on. There were many years of transition where some web services would only send xml and others could send xml or json. Eventually all web services gave you the choice of which one it would send. And then, gradually, xml was transitioned out and everything was json.
  - simplotek 4y ago
    > I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford. Douglas Crockford took his time to write up a specification for the JavaScript Object Notation (JSON). That specification is, quite literally, "based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999." It's in the name. There is no way around this. MDN's doc on JavaScript's eval() vs JSON.parse() refer to JSON as "a subset of JavaScript syntax to represent data." Claiming that someone discovered JSON makes as much sense as reading the C standard section on struct initialization and proceed to claim you discovered the C struct notation (CSN). https://en.cppreference.com/w/c/language/struct_initialization https://en.cppreference.com/w/c/language/struct_initializati...
    - irrational 4y ago
      I don’t think that means it was not invented. Otherwise we would have had it years before. What I understand “based on a subset of JavaScript” to mean is, Crockford chose some of the JS data types (object, array, number, string) and invented a string representation of them that could be used as a data interchange format. That was revolutionary. I remember when I first learned about JSON. It felt like Crockford was a genius for coming up with it, and then wondering why nobody else had come up with it before him. There is no way we would have suffered through XML Hell for so many years I’d there had been another option. But there wasn’t another option. Why? Because Crockford hadn’t invented JSON yet.

eallam 4y ago

Yea I really wanted to write "JSON is worse is better" because JSON is great and simple. We really just mean "reading complicated JSON files sucks"

paco3346 4y ago
So why not say that? When I see a tool or service make a claim as simple as "JSON SUCKS" it makes me think I'm not the target audience. I can read a 10 like file without a parser. What I don't like is 7 layers deep, nested, 890 lines long.

KronisLV 4y ago

> I remember when XML was the main data interchange format of the web. That sucked. I wonder why - apart from the "Should this be an element or an attribute?" issues and oddities in various implementations, XML doesn't seem like the worst thing ever. Actually, in a web development context, I'd argue that WSDL that was used with SOAP was superior to how most people worked with REST (and how some do), since it's taken OpenAPI years to catch up and codegen is still not quite as widespread, despite notable progress: https://openapi-generator.tech/ https://openapi-generator.tech/ What does leave a sour taste, however, is the fact that configuration turned into XML hell (not in a web context, but for apps locally) much like we have YAML hell nowadays, as well as people being able to focus on codegen absolved them of the need to pay lots of attention towards how intuitive their data structures are. That said, JSON also seems okay and it being simpler is a good thing. Though personally JSON5 feels like it addresses a few things that some might find missing: https://json5.org/ https://json5.org/ (despite it being a non-starter for many, due to limited popularity/support)

irrational 4y ago
For me, it is because I can do JSON.parse() and boom, it is plain JavaScript objects, arrays, strings, etc. XML was never that simple.
- mdaniel 4y ago
  That's actually a good observation, and one I hadn't previously considered The trade-off of "that simple" is now every JSON tool has to reinvent XML-RPC, XPath, XML Schema, etc. In that way, JSON may be following the path of every other JS thing: arg, this framework is too heavy, I'm going to write a lighter one! ... ok, just with this one other feature .. ok, and this one ... arg, this framework is too heavy!
orthoxerox 4y ago
Namespaces. I know why they were introduced, but they still were an incredible pain to use, especially with SOAP. You want to pass a <Customer> to the update method? No, it must be <Customer xmlns="http://example.com/api/customers/v2 http://example.com/api/customers/v2"> that is wrapped in a <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope">. Oh, you're writing a service? You can't just XPath your way to that <Customer>, because it's a namespaced <Customer>, your XML parser will claim there's no <Customer> in the message, you have to register your namespaces "http://example.com/api/customers/v2 http://example.com/api/customers/v2" and "http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope" and look for /soap:Envelope/soap:Body/c:Customer instead. JSON is annoyingly anal about its commas, but at least it has a single global namespace and I have never encountered a situation where I wished I could disambiguate between two different "customer" objects in my JSON payload.