Again?

I'll probably listen to this at some point and genuinely like hearing about the origins of JSON from Crockford himself.

Apart from that, I'd be surprised if this adds anything to what I've already heard and read ad nauseam, including from Crockford himself.

JSON is just a nice, simple serialization format that compresses well and interoperates acceptly with most programming languages. Most importantly with the language that it was designed to be consumed by: Javascript.

If one needs better performance or better guarantees about serialized data types, I guess one should use Protobuf, and/or ASN.1 (was that even correctly spelled?) or any of the countless other formats I have no clue about.

If you need better schema restrictions and interconnected entities + circular references: use a database, I guess.

At least everything XML has done in this space has more or less failed (e.g. SOAP). Well, failed might be too strong a word.

But all the work on defining data types and schema seems almost independent of the underlying syntax.

Since I've now spent too much time on this uninformed first comment, I will now listen what Douglas Crockford wants to say. But I think I've already read this story in another form a couple of years ago.

JSON is really a good example of "worse is better". E.g. an OpenAPI spec with automated client code and TypeScript definitions is not much different from SOAP on the surface level.

Two things where imho XML performs well:

1: text with markup. Does not need all the XML machinery, but tags make a lot of sense here.

1b: Arbitrarily nested stuff

2: extensability by third parties without coordination. Namespaces as a central concept help out a lot here, and this use case can even justify some of the more insane features of XML (downloading remote schemas etc)

If you don't need either of those things, you won't get much value out of XML. If you do need them, XML can be neat. Certainly easier than trying to allow people to add arbitrary data (with validation) to your protobuf. It's just that these use cases are somewhat rare

XML tends to be more feature-rich than people need, but what's really lacking in JSON is any support for using custom types to disambiguate polymorphism.

I can't seem to find it, but there's a serialization that's basically Python, so

    Stuff(a=10, b={"foo": bar})