3 ms·
Aside from the ad hominem attacks on JSON, WWW etc. The fact is that a binary format needs exactly the same level of specification as a text based one. ASN.1 is
by rswail 7y ago
Aside from the ad hominem attacks on JSON, WWW etc. The fact is that a binary format needs exactly the same level of specification as a text based one. ASN.1 is a binary TLV encoding mechanism.
The fact that Fastmail, a well known business that is entirely based on successful deployment of email to paying customers has defined a protocol for object exchange etc that is based on Internet RFCs and standards is a Good Thing.
"Cretins" don't decide to use JSON, JSON is an object encoding that is supported by all languages and environments. It compresses to the same level as binary based encodings. It allows for arbitrary extensions that can be migrated in production without having to update all clients/servers simultaneously.
Binary formats tend to be brittle and require simultaneous end-to-end upgrades to handle change. Protobufs and other TLV based encodings help with this, but they still require recompilation and synchronization of IDL specifications.
Compression and caching are easy to insert into a network pipeline (and/or a process-to-process pipeline) easily and transparently. If you read Fielding's thesis on REST, one of the advantages of the HTTP "stack" (not HTML) is that caching and other "dependency injection" can occur transparently between the endpoints.
Efficiency is not by putting all your eggs in one basket. Efficiency comes from a) designing the protocol well, b) keeping the encoding decisions well away from the protocol's content so that decisions like caching and compression etc can all be added or removed without changing the underlying implementation.
All languages "accept" a "numerical format" (not sure what you mean here, but I assume you mean binary encoding. Unless you mean arbitrary length binary numbers. Do you think binary should continue to be on octet boundaries? Or are you talking about encoding an arbitrary bit length? How will you deal with word endianess?
JSON has some warts, the quoting of keys is a pain, the fact that comments cannot be included (but ignored) in the same way as whitespace makes it harder to document configurations or other static documents. The use of floating point is another wart, but if you are sending any numeric values that rely on floating point accuracy, your protocol is wrong. Define a fixed point integer definition instead (eg send monetary values in cents, not dollars).
Email obviously does need this "drivel".