[Proposal] Native CBOR or MessagePack support

CBOR and MessagePack are both binary equivalents to JSON. They use the same data structure as JSON, so they are fully compatible with JSON, but because they are binary the formats are smaller and faster to compress and decompress. The main reason not to use them is because browsers have native support for deserializing JSON (i.e. JSON.parse). This code is native to the browser and highly optimized. To deserialize CBOR or MessagePack you have to use JavaScript libraries which are not as efficient as native code.

So, my proposal is to add full support for CBOR and/or MessagePack at the native browser level. You would have CBOR.encode and CBOR.decode methods (or msgpack.decode and msgpack.encode) just as we have JSON.stringify and JSON.parse.

I think that this would provide a significant improvement in transmission and encoding/decoding speed.

I’m not entirely sure about MessagePack (I haven’t read up on it and haven’t used it personally), but CBOR can have some interesting interoperability issues.

One of the problems I’ve noticed while working with CBOR is that it allows integer keys (which can be more efficient) in objects, but it’s unclear how this should be treated in JavaScript. For usecase, we needed support for integer keys due to interoperability with the backend code (and to save space), but that doesn’t work for everyone. (If MessagePack is anything like CBOR, it will have similar issues)

CBOR also allows explicit precision for float types, which has a risk of lossy conversion.

This could mean subsetting features to find the most interoperable common denominator, which could be problematic as CBOR at least has already been published as a RFC.

Related discussion:

The CBOR RFC spec says:

In applications that need to interwork with JSON-based applications, keys probably should be limited to UTF-8 strings only; otherwise, there has to be a specified mapping from the other CBOR types to Unicode characters, and this often leads to implementation errors.

I think that choosing the interoperable common denominator is already explicitly allowed by the CBOR spec.

(I’m reviving this topic since it’s all I can find on this idea. Since CBOR is now an official Internet Standard it would, IMO, be sensible for browsers to expose it natively.)

Non-string keys can be handled by deserializing CBOR maps/objects to JavaScript Map objects rather than POOs. (IMO JSON.parse() would more ideally have been implemented that way, but of course Map postdates native JSON.)