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.
> 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/
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/ (despite it being a non-starter for many, due to limited popularity/support)
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"> that is wrapped in a <soap:Envelope xmlns:soap="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" and "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.
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!
It's not the worst ever (that would be YAML) but it does have an accumulation of annoying features.
* Elements and attributes (as you said).
* Text children mixed up with elements. These two are both good for writing documents by hand (i.e. HTML) but really annoying to process.
* Namespaces are frankly confusing. I understand them now but I didn't for years - why is the namespace a URL but there's nothing actually at that URL? 99% of the time you don't even need namespaces.
* The tooling around XML is pretty good but it's all very over-engineered just like XML.
* The syntax is overly complicated and verbose. Repeated tag names everywhere. Several different kinds of quoting.
* XML schema is nice but it would be good if there was at least some support for basic types in the document. The lack of bool attributes is annoying, and there's no standard way to create a map.
JSON is better by almost every metric. It is missing namespaces but I can't think of a single time I've needed that in JSON. Mixing up elements from different schemas in the same place is arguably a terrible idea anyway.
The only bad things about JSON are the lack of comments and trailing commas (which are both fixed by JSON5) and its general inefficiency.
The inefficiency can be sometimes solved by using a binary JSON style format e.g. CBOR or Protobuf. With very large documents I've found it better to use SQLite.
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.
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.
> 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.
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.
> 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).
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.
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.
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.
> 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.
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.