The zen of JSON is it's a schema-free, self-describing structure. If people can be bothered to deal with schemas, they can probably also consume the Protobuf s

The zen of JSON is it's a schema-free, self-describing structure. If people can be bothered to deal with schemas, they can probably also consume the Protobuf serialization of a particular object. JSON is targeting a market that doesn't want to do that. There's no reason such an audience can't also reap the benefits of richer types and cryptographic authentication. TJSON aims to provide these benefits to programmers who don't necessarily want to consume schemas up-front to integrate. This is particularly useful for tools which consume a small number of fields. There's a lot of overhead to pulling in IDL definitions (and keeping them up-to-date), and often it's coupled to boilerplate code generation systems. If you're just plucking a few fields from an object here and there, there's no need to go through that ceremony. I say this as someone who's defining the data model in Protobufs. If you're doing any serious data access / API integration: use protobufs. But JSON is a nice fallback for simpler integrations. That is quite literally the point of going through this whole exercise.