Why not Protobuff?

[nskazki]

If I'm to lose readability in favour of efficiency, I can as well use a community standard https://github.com/protobufjs/protobuf.js. In which cases JCOF would be preferable?

[mortie]

I see protobuf and JCOF as serving different goals. Protobuf is a schema-based format with all the pros and cons that entails, and it complicates the build process by requiring a .proto compile step. JCOF is a self-describing schemaless format like JSON, and it's a normal library.

One use-case where JCOF is clearly preferable to protobuf is if you already have an application which uses JSON to serialize stuff; replacing JSON.parse with jcof.parse and JSON.stringify with jcof.stringify is all you need for a significant decrease in the size of your serialized objects.

Also, if you have an API or something which accepts JCOF, humans can write JCOF documents as plain text just like they can with JSON. Understanding the response is tricker, but that's also pretty doable at least with smaller objects. So it's much more human friendly than protobuf even though it's less human friendly than JSON.

Just being a plain-text format is also pretty advantageous in many cases, since it allows copy/pasting. Base64-encoded protobuf would have this advantage too, but most systems which use protobuf won't accept or output base64-encoded protobuf.

[nskazki]

Thanks for the clear answer! Consider adding this to the readme.

[riking]

Flippant version: Protobuf is only "self describing" if you're okay with numbers for field names.