JSON is close to using the most fundamental logical primitives needed to structure serialized data. It's a set of value types, an ordered collection and a key-value collection.

With a syntax that's ridiculously easy to write a parser and generator for (with the one exception of high unicode character escape sequences being encoded as two \uXXXX escapes after each other which form a surrogate pair rather than one \uXXXXXXXX escape, which is a bitch to deal with unless you use UTF-16 internally). It's certainly easier to write a mostly-correct JSON parser than an XML parser.

But why not just return hypermedia, assuming a web page?

What do you mean? JSON can be hypermedia, you can even click hyperlinks in browsers.

You can't return JSON to the browser. (I mean you can, but why lol?)

You have to interpret both up and down stream with a JSON parser (usually JS). In contrast, you can return hypertext/hypermedia directly to the browser and the user can interact with it immediately, without needing translation layers.

A primer: https://dev.to/rajasegar/html-over-the-wire-is-the-future-of...

Because it is a vast improvement over XML, the thing that XMLHttpRequest was designed to be used for. It was supposed to be an http request for a DTD'd XML asset, and thank god we stopped using it for that and went "no that's okay, it doesn't enforce XML compliance, we'll use it for any text content we want, thanks".

Which of course turned out to be incredibly dangerous when that text is (or is derived from) user-generated content, and that's where JSON comes in: JSON is a true data format, instantly turned into the native object that you can work with in the programming language that browser already has to speak in order to be considered a real browser. In stark contrast to XML, which ironically can't be turned into a data object, it can only be turned into a full fledged, separate document that you then need to use additional APIs for in order to extract data from.

XMLHttpRequest was a bad idea that worked because it was also the best option because it was the only option. Thank goodness we moved on.

I didn't mean to emphasize the 'XML' part of XMLHttpRequest; the payload can be anything. I think it always could be anything; I think it's always been possible to retrieve the unparsed raw data.

I know, hence the part where we decided to ignore XML and go for "arbitrary text", which is incredibly dangerous once we started working with user-generated content that we retrieved from a database and then injected into pages as innerHTML content, or loaded as off-page DOM fragment that we'd then copy nodes out of. In both cases, exploits were near-trivial.

Using JSON to communicate just the content that needs to be shown, and making the client-side JS load that in directly (no parser behind JSON.parse required) so we can either template that into the page, or create some DOM nodes that we know are safe because we're setting textContent, not innerHTML, is immensely better.

Could you do the same by sending yaml, or toml, or ini, or cfg or etc. etc. etc.? Probably, but browsers don't natively load any of those, whereas they do natively load JSON. Especially since the Fetch API landed way back in 2015. Native json loading has been a thing for 7+ years now.