4 ms·

Depends on what you're doing... for real-time data streaming, sure... for request-response, I'm less convinced. JSON being human readable, relatively lightweig

Depends on what you're doing... for real-time data streaming, sure... for request-response, I'm less convinced. JSON being human readable, relatively lightweight, and highly compressible is pretty convincing. I'm not against messagepack or protobuf, however, much like all things, I'd rather start with simple http+gz+json (maybe websockets) and optimize as needed. Not everyone is at the scale of FAANG, and most don't really need this level of optimization.

aledalgrande 7y ago
Agree. Most systems have to be optimized in other areas first and I wouldn't give up the debuggability of JSON for a fraction of percent of increase in performance.
IshKebab 7y ago
Protobuf is entirely different to MessagePack and JSON because it has a schema.
- tracker1 7y ago
  schema isn't part of the actual encoding though afaik.
SlowRobotAhead 7y ago
>[JSON] relatively lightweight Um... no? Epoch as binary, 4 bytes. As JSON, 10 bytes. 64bit big num in binary, 8 bytes, in JSON 19 bytes. For a small example object I can think of { “x” : “y” } In binary, 5 bytes. In JSON, 9 bytes. Now... light ENOUGH because you’re using a PC and gigs of ram and a 100mbit internet, sure. Light in terms of a microcontroller? No. I flat out could not use JSON in any of my projects and I’m not at FAANG level.
- tracker1 7y ago
  seems like what you're talking about would fall under the real-time streaming category... HTTP overhead alone would outweigh the JSON differences you're talking about.
  - SlowRobotAhead 7y ago
    Double. That's the inefficiency you can count on with JSON over CBOR or MsgPack if you're dealing with number data or short strings. Sure, the HTTP overhead and TCP overhead under that are significant if you're transferring a single bignum. How about 10,000 of them? Even if the best case of all strings where binary gets limited by ASCII's inefficiency, "":"", is "only" 5 bytes of wasted data, but what about a million item JSON? 5 million wasted bytes does seem like it outpaces NIC then TCP then HTTP layer overhead. But uea, IDK. The claim was that JSON is lightweight, it is not. It's not as bad as XML, I'll give it that.

aledalgrande 7y ago

Agree. Most systems have to be optimized in other areas first and I wouldn't give up the debuggability of JSON for a fraction of percent of increase in performance.

IshKebab 7y ago

Protobuf is entirely different to MessagePack and JSON because it has a schema.

tracker1 7y ago
schema isn't part of the actual encoding though afaik.

SlowRobotAhead 7y ago

>[JSON] relatively lightweight Um... no? Epoch as binary, 4 bytes. As JSON, 10 bytes. 64bit big num in binary, 8 bytes, in JSON 19 bytes. For a small example object I can think of { “x” : “y” } In binary, 5 bytes. In JSON, 9 bytes. Now... light ENOUGH because you’re using a PC and gigs of ram and a 100mbit internet, sure. Light in terms of a microcontroller? No. I flat out could not use JSON in any of my projects and I’m not at FAANG level.

tracker1 7y ago
seems like what you're talking about would fall under the real-time streaming category... HTTP overhead alone would outweigh the JSON differences you're talking about.
- SlowRobotAhead 7y ago
  Double. That's the inefficiency you can count on with JSON over CBOR or MsgPack if you're dealing with number data or short strings. Sure, the HTTP overhead and TCP overhead under that are significant if you're transferring a single bignum. How about 10,000 of them? Even if the best case of all strings where binary gets limited by ASCII's inefficiency, "":"", is "only" 5 bytes of wasted data, but what about a million item JSON? 5 million wasted bytes does seem like it outpaces NIC then TCP then HTTP layer overhead. But uea, IDK. The claim was that JSON is lightweight, it is not. It's not as bad as XML, I'll give it that.