MessagePack

[Azareal]

https://msgpack.org/index.html
It's a serialization format which maps fairly closely to JSON, but instead of using text, the data is sent over in binary making it far more compact and faster to encode / decode.

https://github.com/alecthomas/go_serialization_benchmarks
It would appear that it's around ten times faster than JSON, for Go at-least. Intriguing, to say the least.

To read those benchmarks, like most Go benchmarks, you just have to know that an op is a call to the serialization function, and then, the benchmark tool (aka go test) runs the function a million times (the number of times is on the left of it), calculates out the average, and spits out the results for it.

If you're confused by the terminology used there:
Marshalling is the process of encoding a struct or some other bit of data in the serialized format. Unmarshalling is the opposite.

I find the results intriguing, although MessagePack's performance crashes like a brick on JavaScript (it's not too shabby there either) due JSON being implemented in assembly / C++ there while the MessagePack parser is written in JavaScript.

The main downside is that as a binary format, you can't read it without throwing it into a deserializer in the same way you can for JSON.

 

[Cosmic]

Hmm. JSON performs better in the browser? That would seem to be an important advantage. Backend services can scale, while a user’s browser has fixed and often limited resources.

Is the encoded data readable in a console? That’s another benefit of JSON; browsers know how to display well. Chrome will add folds and such in the dev tools.

Compression also isn’t as important at the application layer, because that can be handled at the SSL layer. Data is still compressed when transmitted, but applications automatically deal with uncompressed data. Less complication.

 

[Azareal]

Hmm. JSON performs better in the browser? That would seem to be an important advantage. Backend services can scale, while a user’s browser has fixed and often limited resources.

Is the encoded data readable in a console? That’s another benefit of JSON; browsers know how to display well. Chrome will add folds and such in the dev tools.

Compression also isn’t as important at the application layer, because that can be handled at the SSL layer. Data is still compressed when transmitted, but applications automatically deal with uncompressed data. Less complication.

It's the other way around, actually. Any message sent to the browser is going to have a tiny insignificant weight, and any that are big to be relevant are going to be significantly faster.

This is because MessagePack becomes exponentially faster as the message size increases due to it being a far simpler algorithm. It's mainly slow for small messages, likely due to the over-optimised assembly JSON parser, integration with the browser, etc. and again, only with JavaScript (it's fast elsewhere, unless you're rolling a pure PHP parser).

And you will likely decode it, then push through the object to the console to look at, if you really want to look at it.

In addition, a server is likely to step through ten thousand, or even a hundred thousand users every time something of note happens. Memory will get allocated, deallocated, and packets sent.
A smart server may even take opportunities to only encode data once and to reuse the same set of bytes for them all, if possible.

 

[Cosmic]

JSON computations can also be cached if it becomes an issue. At the end of the day, everything’s bytes. Adding a new console log into the frontend is often much less convenient than just looking at the network panel. Chrome lets you click in and see all XHR or other resource requests with just a couple clicks. You can see the request, headers, response, timeline, etc. With JSON it even lets you drill down into the request and response really easy, which is super useful for a large response.

 

[Azareal]

JSON computations can also be cached if it becomes an issue. At the end of the day, everything’s bytes. Adding a new console log into the frontend is often much less convenient than just looking at the network panel. Chrome lets you click in and see all XHR or other resource requests with just a couple clicks. You can see the request, headers, response, timeline, etc. With JSON it even lets you drill down into the request and response really easy, which is super useful for a large response.

Another thing to consider is that compressing / decompressing takes computational power and time. Not to mention, complexity.

MessagePack has libraries in over 50 languages. Asides from Google's protobufs which have their own problems (the server has to tell the client what format to expect, you can generally just swap JSON out fairly easily for a more graceful migration, etc.), it's the closest to being a standard.

A simpler implementation also means that it is easier to optimise and it is easier to audit helping to prevent security vulnerabilities. In addition to that, you aren't relying on " as a delimiter further reducing the chances of security issues.

Also, some of the methods people use to write ultra-fast JSON parsers are becoming somewhat concerning like abuse of AVX instructions which slows down the entire core in exchange for the parser running fast, although that's just a problem with some of the parsers.

I'll also add that micro-service architectures spend a disproportionate amount of time parsing JSON. Also, you can't cache everything. Although, you can certainly try.