4 ms·

While very informative and interesting, I don't think your comment really engages with my point. I never mentioned Erlang or functional programming. I'm just ta

by ggreer 11y ago

While very informative and interesting, I don't think your comment really engages with my point. I never mentioned Erlang or functional programming. I'm just talking about data serialization. Namely, that sending JSON or XML over the air isn't "totally crazy". Again, the vast majority of mobile data isn't JSON or XML. If mobile bandwidth was a Californian drought, video would be alfalfa farming. JSON would be taking a long shower: maybe you feel a little bad, but it doesn't matter. All the short showers in the world can't make up for the huge volume of water (bandwidth) used by alfalfa (video). Obviously, if you have a billion users, trade-offs change and it can make sense to use esoteric or bespoke protocols. But even for Facebook, using JSON isn't crazy. It's just inefficient. And Facebook didn't switch to FlatBuffers for the bandwidth savings. Their primary goal was to improve loading times for their local cache. Had FlatBuffers required 10% more network traffic than JSON, they likely still would have made the switch.

rdtsc 11y ago
> I don't think your comment really engages with my point. I never mentioned Erlang or functional programming [...] Sorry. It was mainly a response to "JSON and XML are only 'wasteful' if you don't count developer time. Once you do, it suddenly makes a lot of sense to "waste" hardware resources. After all, programmers are expensive. Hardware is cheap." And pointing out that it really depends on what languages or type or programmers you use and what "hardware" is. In some languages binary parsing is really easy and just as cheap and elegant as using a json parser. And well, Joe is Erlang's father, so point out Erlang was obvious choice. As for hardware, bandwidth is not hardware. It really is "something else" -- a shared resource usually. And if there are enough devices using this even small changes start to make a difference. Think a bit like a nested loop -- a small optimization in the inner loop might have large visible benefits. Or say, a huge database with 10B records, choosing an 32bit int vs an 16bit one for a column will make a for a good difference in size. That is basically where Joe was coming from. Really valuing bandiwidth as a shared resource. (He also likes to talk about protocols as well quite a bit). > Again, the vast majority of mobile data isn't JSON or XML The important data is JSON though, the control message, the pages that load (and they are slow), stuff that stops, start, manages everything all that is JSON. > If mobile bandwidth was a Californian drought, video would be alfalfa farming Hmm, video is 50% of all traffic on smart phones. (http://www.ericsson.com/res/docs/2015/ericsson-mobility-report-june-2015.pdf http://www.ericsson.com/res/docs/2015/ericsson-mobility-repo... says 45% in 2014). Not that the rest is all JSON but, I wouldn't say it is all just "taking showers" type of equivalency, it is more like grapes, almonds, strawberries, and walnuts.
- kbutler 11y ago
  Remember to also subtract images, audio, and other actual content and code from the remaining 50%. And realize that if you're using a flat structure to encode hierarchical data, you'll have to encode that hierarchy somehow. Then subtract compression.
  - Ntrails 11y ago
    My money is on the fact that ad blockers save several times the bandwidth per user that could possibly be saved by a switch away from JSON/XML. Ignoring everything else there are much lower hanging fruit to save bandwidth.
- deleted 11y ago
  [deleted]

by ggreer 11y ago

rdtsc 11y ago

> I don't think your comment really engages with my point. I never mentioned Erlang or functional programming [...] Sorry. It was mainly a response to "JSON and XML are only 'wasteful' if you don't count developer time. Once you do, it suddenly makes a lot of sense to "waste" hardware resources. After all, programmers are expensive. Hardware is cheap." And pointing out that it really depends on what languages or type or programmers you use and what "hardware" is. In some languages binary parsing is really easy and just as cheap and elegant as using a json parser. And well, Joe is Erlang's father, so point out Erlang was obvious choice. As for hardware, bandwidth is not hardware. It really is "something else" -- a shared resource usually. And if there are enough devices using this even small changes start to make a difference. Think a bit like a nested loop -- a small optimization in the inner loop might have large visible benefits. Or say, a huge database with 10B records, choosing an 32bit int vs an 16bit one for a column will make a for a good difference in size. That is basically where Joe was coming from. Really valuing bandiwidth as a shared resource. (He also likes to talk about protocols as well quite a bit). > Again, the vast majority of mobile data isn't JSON or XML The important data is JSON though, the control message, the pages that load (and they are slow), stuff that stops, start, manages everything all that is JSON. > If mobile bandwidth was a Californian drought, video would be alfalfa farming Hmm, video is 50% of all traffic on smart phones. (http://www.ericsson.com/res/docs/2015/ericsson-mobility-report-june-2015.pdf http://www.ericsson.com/res/docs/2015/ericsson-mobility-repo... says 45% in 2014). Not that the rest is all JSON but, I wouldn't say it is all just "taking showers" type of equivalency, it is more like grapes, almonds, strawberries, and walnuts.

kbutler 11y ago
Remember to also subtract images, audio, and other actual content and code from the remaining 50%. And realize that if you're using a flat structure to encode hierarchical data, you'll have to encode that hierarchy somehow. Then subtract compression.
- Ntrails 11y ago
  My money is on the fact that ad blockers save several times the bandwidth per user that could possibly be saved by a switch away from JSON/XML. Ignoring everything else there are much lower hanging fruit to save bandwidth.
deleted 11y ago
[deleted]