So MessagePack wants me to ditch one of the most portable widely used data transfer formats in the world to save 33% on message size? No thanks. I'm willing to bet that using Content-Encoding: gzip on the JSON would negate most of the size difference anyway.

But that also uses double precision floating point number representation and UTF-8 for strings, so the only benefit (according to the arguments given in the OP) seems to be text vs. binary-based.

> But that also uses double precision floating point number representation

I don't think JSON requires the number representation to be double-precision, that can be up to the parser to decide how to represent a number. I think most people misrepresent this because the number implementation in JavaScript is double-precision, but that's not necessarily true for JSON. Am I wrong about that? Does JSON require the number format to be double-precision?

I had to check but yeah, that's true, the ECMA spec even says explicitly in its intro: "JSON is agnostic about numbers", they are "only a sequence of digits".

(Unrelated observation from looking at the spec again: there's no standard/recommended decoding behaviour if an object has several members with the same key.)

This does look pretty cool. I think the author is forgetting about so many reasons why JSON is so widely used, however.

One huge benefit of JSON over msgpack or something similar is READABILITY.

It sure looks impressive, thanks for linking