Yes, JSON was not designed for this sort of thing; it was designed to follow the Javascript object model, which is VERY limited. It was a quick and clever hack

Yes, JSON was not designed for this sort of thing; it was designed to follow the Javascript object model, which is VERY limited. It was a quick and clever hack to get serialization working between Javascript systems, so it did mostly solve the problem of rehydrating whole objects (in JS). The only tricky problem is if you change the data structure and then try to rehydrate from an old document (the same problem you encounter in databases when you change the schema). And most use cases have done alright despite that. But of course once you take JSON and try to make it work in other languages, you run into trouble with the lack of types. There have been many attempts at serialization formats that cover the 80% case, each with varying levels of success. The thing is, JSON and XML opened the door to a new requirement: human readability. Nowadays we want to be able to inspect and edit the data without needing some kind of specialized binary editor to do it. We want to be able to load it up into our text editor of choice, make changes, and expect it to work when fed into the machine. That's huge, and marked a paradigm shift in data communications and serialization (despite the terrible inefficiencies this introduces). But it's always been the lack of types that tripped up nontrivial use cases, requiring all sorts of unportable hacks and workarounds to shoehorn it into your particular use case. I've been developing Concise Encoding [1] over the past 3 years specifically to tackle this problem. For the 80% use case, the format must: - Be ad-hoc capable (most real-world use cases don't actually need a schema) - Be human readable/writable as text - Be efficient (don't waste energy constantly serializing/deserializing text) - Support all common types (bool, int, float, date, URL, UUIDs, list, map, array, etc) - Support recursive data - Support pseudo-objects like comments and metadata - Be precise (no lossy conversions from things such as floats) Also another pet peeve of mine is date formats. Pretty much every serialization format either gets it wrong, or doesn't support all of the cases it should (this includes ISO-8601). [1] https://concise-encoding.org https://concise-encoding.org