This is lame and not HN-worthy because the use cases are almost zero.
0. Premature optimisation is the root of all evil
1. Approximately zero big sites use ruby
2. Of large sites, very few would actually care that much about tiny on-wire messaging optimisation since other elements are far more significant to bandwidth use.
3. On-wire messaging in binary destroys transparency, which means PITA debugging and wasted programmer and API-using developer time. Programmer time is far more important than computer time or a few bytes of bandwidth in most developed nations.
4. You have to pay for the binary serialisation with additional client-side code, which means you've actually gone backwards until you've communicated enough that the delta between JSON and binary format message sizes have outgrown this initial load time penalty.
5. Initial load time penalties are often more important than subsequent use, since generally this is the only time client bandwidth (the only side of the bandwidth equation relevant to performance in 99.99% of cases) is going to be challenged to any serious level.
6. Refer to point zero.
0. Few people who use this quote actually know its origin and context.
1. Scribd, Hulu, Justin.tv, Slideshare... there are tons of ruby sites in the top 500, not just Twitter.
2. Serialization isn't just on the wire, it also may be stored in memcache or the like. But even on the wire, crossection bandwidth is scarce in large clusters. There's a reason google developed protocol buffers.
3. Debugging by wire sniffing is shitty period. I don't think binary vs ascii is very meaningful. What matters more is the infrastructure on each end, eg do the client and server have good reflection, monitoring and logging capabilities. These are what affect programmer time.
4. This is a RPC format. Sending payloads to browsers is not a use case. Even so on modern javascript implementations decoding a byte packed binary format is likely faster than the eval path used by naive browser JSON parsers because it doesn't build any intermediate forms like token streams, ASTs, etc.
0. Premature optimisation is the root of all evil 1. Approximately zero big sites use ruby 2. Of large sites, very few would actually care that much about tiny on-wire messaging optimisation since other elements are far more significant to bandwidth use. 3. On-wire messaging in binary destroys transparency, which means PITA debugging and wasted programmer and API-using developer time. Programmer time is far more important than computer time or a few bytes of bandwidth in most developed nations. 4. You have to pay for the binary serialisation with additional client-side code, which means you've actually gone backwards until you've communicated enough that the delta between JSON and binary format message sizes have outgrown this initial load time penalty. 5. Initial load time penalties are often more important than subsequent use, since generally this is the only time client bandwidth (the only side of the bandwidth equation relevant to performance in 99.99% of cases) is going to be challenged to any serious level. 6. Refer to point zero.