4 ms·

JSON won, IMO, because it's human readable and writable. It came at a time when its main competitor in this space - XML - had gotten too complex. However, JSON

JSON won, IMO, because it's human readable and writable. It came at a time when its main competitor in this space - XML - had gotten too complex. However, JSON is hitting the same limitations and problems that XML faced, and is following in their shoes (namespaces, schemas, x/jpath, implementation drift across libraries, etc).

krapp 6y ago
JSON won because the web and javascript, which supports JSON, won. It would have won regardless of how ugly or awkward it was for that reason alone.
- iakh 6y ago
  Except that the x in ajax stands for xml
  - krapp 6y ago
    JSON is already based on javascript's object model so it makes more sense to pass it around instead of a format not natively supported by the language that will be processing it.
jjoonathan 6y ago
Yeah, but they were reinvented in JSON, with the key difference that you didn't have to pay for them if you didn't need them. JSON unbundled XML.
- Spearchucker 6y ago
  The same was true for XML.
  - jjoonathan 6y ago
    It really wasn't. Implicit remote resource dependencies, validation, namespaces, and parser-settings dependence of all of these were huge footguns. You could turn these features off if you controlled the format and parser, but you might not, and in any case you would have to understand the features to ensure you wouldn't trip over them, which meant you couldn't ignore them at zero cost. They were syntactically unbundled but not conceptually unbundled. XML had zero sympathy for the casual user and the results were 100% predictable, earned, and deserved.
    - Spearchucker 6y ago
      But the same is true for JSON. Of course you're going to be constrained by a legacy system of you're constrained by a legacy system. Neither JSON nor XML force the implementor to use any of the crazy stuff.
      - jjoonathan 6y ago
        In theory that's true, but in practice out-of-the-box defaults and culture matter enormously and differ greatly between JSON and XML. With JSON, you have to go looking for this sort of trouble if you want to find it. An out-of-the-box JSON parser is all but guaranteed not to coerce a schema, fetch remote resources, apply namespaces, and so on -- if you want to do those things, you have to go out of your way to do them, and your decision to do so is likely motivated by considering tradeoffs rather than cargo-culting because the decisions are A) explicit and B) made in a cultural context where schema-free and remote-ref-free JSON is common practice rather than a sneered-upon possibility. With XML, you don't have to go looking for trouble, the trouble finds you. XML's ecosystem absolutely did push everyone in the direction of using schemas and remote-refs. DTDs were both common and encouraged with a heavy hand. All the Big Protocols used them, and instead of emphasizing the differences between Big Protocol use cases and duct-tape use cases, the culture tended to get preachy about DTDs being "the right way" to do things. If you chose differently, you were amateur scum not worthy of the Enterprise. This encouraged cargo-cult application of DTDs in places where they weren't appropriate (e.g. maximally economic / flexible glue) and for purposes that weren't appropriate (e.g. as a substitute for documentation). It also lent "moral license" to the wrong party in validation-related toe-stepping. Party A turns on validation, Party B sees their integration stop working, Party A argues that if Party B hadn't been writing morally degenerate XML they wouldn't have been caught out and can point at an abundance of preachy XML gospel to back them up. Party A gets away with arguing that an API change isn't an API change, or that a new internet/VPN dependency isn't new. Party B gets trod upon and remembers that XML was complicit in it. Sure, the XML ecosystem could have avoided these problems without a single code-change or standards-change by creating a culture of acceptance around schema-free XML, but they didn't. When JSON promised both cultural acceptance and appropriate defaults for the common low-rent use case, people flocked to it, and rightly so. The rest is history.
kerkeslager 6y ago
Ehhhh, is it hitting those limitations? I've yet to run into a problem in which would be solved by adding Enterprise™ silliness. And is it following in XML's shoes? I've not had to work on or integrate with any systems that did this Enterprise™ silliness either. Now granted, I'm fairly separated from the world of IBM and SAP type companies, and I'm sure there's all sorts of unholy abuse of JSON going on in a dark server room somewhere, but the answer in most cases is just to choose technology stacks that don't do that to you. These problems are generally self-imposed rather than imposed by the technology.
- falcolas 6y ago
  > Ehhhh, is it hitting those limitations? Yes. Some folks, even at my relatively small company, are using JSON and also pushing for extensive schema use. JSON - just like XML - allows you to use its vanilla form. But the additional tools are available if/when you need them, because the need exists.
  - kerkeslager 6y ago
    Just because people are pushing for them doesn't mean they are needed. I have no idea what your needs are, so maybe they are needed at your company. All I can say is, I've never come across a need for them but I have met a lot of people who just want to try things out because they think it might be cool.
- kstrauser 6y ago
  > Ehhhh, is it hitting those limitations? I've yet to run into a problem in which would be solved by adding Enterprise™ silliness. I think that's why JSON won: it was first and foremost and engineer-driven standard as opposed to one that incubated inside a bunch of enterprises before being dropped on an unsuspecting world.
  - falcolas 6y ago
    SGML, XML's predecessor, was definitely engineer built (the wiki page is interesting). It just paved the same path that JSON is now traversing. Given that XML is roughly 34 years old (or GML, which was SGML's predecessor and is about 60 years old), give JSON just a bit more time to get to the same level of 'blech'.

krapp 6y ago

JSON won because the web and javascript, which supports JSON, won. It would have won regardless of how ugly or awkward it was for that reason alone.

iakh 6y ago
Except that the x in ajax stands for xml
- krapp 6y ago
  JSON is already based on javascript's object model so it makes more sense to pass it around instead of a format not natively supported by the language that will be processing it.

jjoonathan 6y ago

Yeah, but they were reinvented in JSON, with the key difference that you didn't have to pay for them if you didn't need them. JSON unbundled XML.

Spearchucker 6y ago
The same was true for XML.
- jjoonathan 6y ago
  It really wasn't. Implicit remote resource dependencies, validation, namespaces, and parser-settings dependence of all of these were huge footguns. You could turn these features off if you controlled the format and parser, but you might not, and in any case you would have to understand the features to ensure you wouldn't trip over them, which meant you couldn't ignore them at zero cost. They were syntactically unbundled but not conceptually unbundled. XML had zero sympathy for the casual user and the results were 100% predictable, earned, and deserved.
  - Spearchucker 6y ago
    But the same is true for JSON. Of course you're going to be constrained by a legacy system of you're constrained by a legacy system. Neither JSON nor XML force the implementor to use any of the crazy stuff.
    - jjoonathan 6y ago
      In theory that's true, but in practice out-of-the-box defaults and culture matter enormously and differ greatly between JSON and XML. With JSON, you have to go looking for this sort of trouble if you want to find it. An out-of-the-box JSON parser is all but guaranteed not to coerce a schema, fetch remote resources, apply namespaces, and so on -- if you want to do those things, you have to go out of your way to do them, and your decision to do so is likely motivated by considering tradeoffs rather than cargo-culting because the decisions are A) explicit and B) made in a cultural context where schema-free and remote-ref-free JSON is common practice rather than a sneered-upon possibility. With XML, you don't have to go looking for trouble, the trouble finds you. XML's ecosystem absolutely did push everyone in the direction of using schemas and remote-refs. DTDs were both common and encouraged with a heavy hand. All the Big Protocols used them, and instead of emphasizing the differences between Big Protocol use cases and duct-tape use cases, the culture tended to get preachy about DTDs being "the right way" to do things. If you chose differently, you were amateur scum not worthy of the Enterprise. This encouraged cargo-cult application of DTDs in places where they weren't appropriate (e.g. maximally economic / flexible glue) and for purposes that weren't appropriate (e.g. as a substitute for documentation). It also lent "moral license" to the wrong party in validation-related toe-stepping. Party A turns on validation, Party B sees their integration stop working, Party A argues that if Party B hadn't been writing morally degenerate XML they wouldn't have been caught out and can point at an abundance of preachy XML gospel to back them up. Party A gets away with arguing that an API change isn't an API change, or that a new internet/VPN dependency isn't new. Party B gets trod upon and remembers that XML was complicit in it. Sure, the XML ecosystem could have avoided these problems without a single code-change or standards-change by creating a culture of acceptance around schema-free XML, but they didn't. When JSON promised both cultural acceptance and appropriate defaults for the common low-rent use case, people flocked to it, and rightly so. The rest is history.

kerkeslager 6y ago

Ehhhh, is it hitting those limitations? I've yet to run into a problem in which would be solved by adding Enterprise™ silliness. And is it following in XML's shoes? I've not had to work on or integrate with any systems that did this Enterprise™ silliness either. Now granted, I'm fairly separated from the world of IBM and SAP type companies, and I'm sure there's all sorts of unholy abuse of JSON going on in a dark server room somewhere, but the answer in most cases is just to choose technology stacks that don't do that to you. These problems are generally self-imposed rather than imposed by the technology.

falcolas 6y ago
> Ehhhh, is it hitting those limitations? Yes. Some folks, even at my relatively small company, are using JSON and also pushing for extensive schema use. JSON - just like XML - allows you to use its vanilla form. But the additional tools are available if/when you need them, because the need exists.
- kerkeslager 6y ago
  Just because people are pushing for them doesn't mean they are needed. I have no idea what your needs are, so maybe they are needed at your company. All I can say is, I've never come across a need for them but I have met a lot of people who just want to try things out because they think it might be cool.
kstrauser 6y ago
> Ehhhh, is it hitting those limitations? I've yet to run into a problem in which would be solved by adding Enterprise™ silliness. I think that's why JSON won: it was first and foremost and engineer-driven standard as opposed to one that incubated inside a bunch of enterprises before being dropped on an unsuspecting world.
- falcolas 6y ago
  SGML, XML's predecessor, was definitely engineer built (the wiki page is interesting). It just paved the same path that JSON is now traversing. Given that XML is roughly 34 years old (or GML, which was SGML's predecessor and is about 60 years old), give JSON just a bit more time to get to the same level of 'blech'.