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.
You're Using JSON, Why not MessagePack?
11–20 of 66 posts
Re: You're Using JSON, Why not MessagePack?
#12because when JSON is Gzip'd there's only around ~5% in it: http://goo.gl/b2Uur (the bit on geojson).
I think you mean 25%. And it comes out ~50% the size of MessagePack after gzipping.
Re: You're Using JSON, Why not MessagePack?
#13Because 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.
Re: You're Using JSON, Why not MessagePack?
#14Changing data formats all the time is usually not worth any of the effort involved. XML to JSON seemed to take long enough, and now that we've got a lightweight, internationally accepted, easy to read by humans and computers alike, data interchange format, I think we'd like to keep it for a while.
Re: You're Using JSON, Why not MessagePack?
#15The "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 .proto file gives you the benefits of something like JSON Schema: a place to document all your fields and what they mean, and a few very simple validation constraints like the expected types.
Re: You're Using JSON, Why not MessagePack?
#16For 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 them, you can write another one in about two hours.
* It's not human-readable. Enough said.
* It's smaller than JSON, sure, but is it smaller than gzipped JSON? PB's aren't for our purposes. Neither are TNetstrings. This might be, I haven't checked, but I doubt it.
Re: You're Using JSON, Why not MessagePack?
#17For 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?
Re: You're Using JSON, Why not MessagePack?
#18For 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?
This is important if you want to use JRuby.
Re: You're Using JSON, Why not MessagePack?
#19Premature optimization?