I used to care about that but once the JSON gets at all complex, it's nice to switch to pretty formatting of it. At that point, a dev tool in the browser could do the same for this format so I don't think that is as pressing (for me and I suspect most people).

Actually , I think thats no longer the case.

(Except if you want to use JSON for configs, which a strongly recommend against for a bunch of reasons including missing support for comments).

I mean by now nearly all times you send thinks over the wire they are ecrypted or at least compressed. So inspecting on-wire messages without "proper" more complex tooling doesn't really work. But if you have already more complex tooling involved there is no reason why you need to be able to read the raw message, it could be just converted on-the-fly into a readable format.

Same applies for application development when e.g. logging, you always do some formatting/conversion when logging some data, so not a problem to convert msg-pack to a human readable format. But then today logging of e.g. servers should always go to some form of log server which does add features like search ability by indexing the log and similar. So no problem to have a msg-pack viewer there, too.

Honestly I believe the only reason human readable formats made/(still do make sometimes) sense was due to limited tooling sometimes caused by server limits in computation power on the developers system. And the fact that many binary formats are totally over engineered making handling of them painful. Especially debugging of slightly corrupted data. Which isn't the case for MsgPack.

Compression is not encryption and security by obscurity is bad practice. So it doesn't matter if the data is json or compressed or protobuf or messagePack or custom struct. As long as it's not properly encrypted, it's just plaintext.

I don't think the parent poster was confusing encryption for compression or suggesting security by obscurity. He just meant that JSON is never sent in pretty-printed plain text over the wire, so you always need tooling to view it.

This has been my experience with JSON as well. Almost all JSON in the wild especially in web services and RPC is at least minified, so you need to pass it through something like `python -m json.tool` to reformat it for viewing. So you might as well use MessagePack and pass it through `msgpack2json -d` to view it instead. It makes no difference whether the underlying format is human readable.

Sure doesn't look like it..

I agree- that's why json is honestly great. I avoided it for the longest time, but now I totally see the appeal.

What did you avoid it in favor of? XML?

it's not. IMO It's a good replacement for ProtoBuf.

Maybe where you want to have a human debug or see what is happening (like in localStorage, or cookies). But if you're going to transfer a significant amount of data between front and back-end, for example, that can save money on a cloud service.

You can easily make a function wrapper that uses JSON in a dev environment and MessagePack in Production, for example.

If you want to transfer a significant amount of data and don' t need readability, using protobufs makes even more sense, since the key names do not go as string on the wire, so the data should be much smaller.

MessagePack lets you use integers for keys, so you can use enums or integer constants in the code instead of strings. There are good reasons to use MessagePack over Protobuf even if you don't need readability, such as easier integration into buildsystems and better support for embedded platforms.

It's taking a different angle from JSON, encoding it in JavaScript is done from standard objects into a UInt8Array.