I miss the days of strongly typed schemas. It's much easier to fail gracefully.
But this comment seems needlessly cynical and doesn't actually offer any rebuttal to the parent's point. I find technical discussions of these sorts of things interesting and a great way for new people to learn about the tradeoffs, maybe you could offer a reasoned opinion on why not use protocol buffers?
One should keep schema in protocol buffers and encourage its use for all but browsers.
This severely limits its usefulness, unless you want to put workarounds of this shortcoming into your application.
Other protobuf-like things like capnproto don't have that restriction, because they don't use 32 bit integers for sizes.
Also even in json, splitting documents in smaller chunks (ndjson for instance) is the standard practice to avoid having to parse it all in one go.
Cap'n Proto is different, since it's zero-copy and random-access. You can in fact read one bit of data out of a large file in O(1) time by mmap()ing it and using the data structure in-place.
Hence, it makes sense for Cap'n Proto to support much larger messages, but it never made sense for Protobuf to try.
Incidentally the 32-bit limitation on Protobuf is an implementation issue, not fundamental to the format. It's likely some Protobuf implementations do not have this limitation.
(Disclosure: I'm the author of Protobuf v2 and Cap'n Proto.)
If I want to perform some rough tests of an endpoint during development, all I need to do is compose the json request and fire it off using curl. The response then comes back in a human readable format I can parse straight from the terminal. Boom, simple test conducted in less than 1 minute. I don't even need to think about it.
Compare that to protobufs; I need to create a custom client or unit test that'll compose and fire off the request I want to test, then I need to write a bunch of code that will introspect the contents of the response so I can pick out the details. Huge time loss, concentration ruined since I need to actually think about the process, I'd rather just take the extra latency that using json will incur.
This skips past all of the other advantages json has over binary serialization protocols, like quickly being able to parse requests while debugging issues, infinite client language support, ease of sharing breaking requests to help devs reproduce problems, not needing to add an extra compilation step to my deployments and packages, etc.
With things like Avro or GPB you still need to validate that the relationship holds true separately.