31–40 of 66 posts
I'm not using JSON or MessagePack because I need to send arbitrary binary data. I understand why people use JSON, and it has its domain (sending data to and from the browser), but in other situations I don't think it is a good protocol. Another poster mentioned tnetstrings, those look interesting, however I am not sure how well those would handle binary data.
Because it isn't human readable, which will make debugging it far less convenient than glancing at some JSON in a browser (or in Firebug).
This. Never liked nor used XML for that exact reason.
Earlier quoted context omitted.
bson messages are often larger than their json counterpart. The benefit of bson isn't size, but rather ease (on the cpu) of serializing and deserializing.
I agree in part. Most of the time JSON and BSON are very similar in size, and sometimes larger (due to length prefixes). But, size benefits do emerge when you need to store binary data inside the object. Instead of a base64 encoded string, the binary data can be stored directly.
I completely understand the need for JSON when you are communicating with the frontend/Javascript. But if you are doing backend messaging, would you not rather use ZeroMQ (which comes with its own protocol).
From what I understand (from previous HN posts), it is super fast and handles binary data very efficiently. I also understand that you can tune stuff at the OS level to wring the last bit of performance from ZeroMQ.
P.S: yup, it is written in C, but all bindings apparently work very well.
I have a naive question - why would I not use something like ZeroMQ for messaging ? I completely understand the need for JSON when you are communicating with the frontend/Javascript. But if you are doing backend messaging, would you not rather use ZeroMQ (which comes with its own protocol). From what I understand (from previous HN posts), it is super fast and handles binary data very efficiently. I also understand th…
For the same reasons we are in the process of switching from Protocol Buffers back to JSON: * It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C? * Even if it does, why have to deal with someone else's poor API design? JSON has a million parsers for everything, and if by chance you don't like any of…
> Is there a Ruby module with no C extension? Why is the "with no C extension" part important to you?
The "4x faster than Protocol Buffers" claim is misleading, as I have explained before: http://news.ycombinator.com/item?id=2146147 I'm working on a Protocol Buffer library that can serialize/deserialize to either JSON or Protocol Buffers. That way you can do all your development with JSON, but if you ever find you need the efficiency improvements of a binary format, you can just change your Serialize() call. Having a…
It's sad, really. The people who try to call bullshit on those sorts of claims are frequently drowned out by those who are blinded by the "4x faster!" etc.
I'm not using JSON or MessagePack because I need to send arbitrary binary data. I understand why people use JSON, and it has its domain (sending data to and from the browser), but in other situations I don't think it is a good protocol. Another poster mentioned tnetstrings, those look interesting, however I am not sure how well those would handle binary data.
I have a naive question - why would I not use something like ZeroMQ for messaging ? I completely understand the need for JSON when you are communicating with the frontend/Javascript. But if you are doing backend messaging, would you not rather use ZeroMQ (which comes with its own protocol). From what I understand (from previous HN posts), it is super fast and handles binary data very efficiently. I also understand th…
They're different types of thing. ZeroMQ doesn't replace JSON, it replaces HTTP. If you're using ZeroMQ it will help you get some bytes from one place to another, but you still need a serialization format. You might well send JSON over ZeroMQ.
Because JSON is around twice as fast to encode/decode in Node, which is where I really need the performance. MessagePack is just slow, complicated, and unnecessary.
Citation needed, especially since the node-msgpack library docs say it's anywhere from 1.2-3X faster. https://github.com/pgriess/node-msgpack
I've done several of my own benchmarks as well and can confirm that the current Node JSON implementation is much faster than MessagePack. Their benchmarks are most likely quite old.