2 ms·

I've built a few "chat apps". I wouldn't discount the complexity. They carry with them a wide array of problem spaces. And of course anything at FB scale user c

I've built a few "chat apps". I wouldn't discount the complexity. They carry with them a wide array of problem spaces. And of course anything at FB scale user counts is going to be a challenge.

Turing_Machine 7y ago
While I have absolutely no doubt there are scalability problems, it seems to me that most of those problems are going to be (or should be) on the back end, not in the client. How is the client 1.7 million lines of code?
- jconley 7y ago
  I can see it. It's pretty easy to hit that much code when you include your own code for things as trivial as a JSON parser rather than leveraging what the native SDK provides (which was alluded to in the article). It sounds like they had a bit of Not Invented Here syndrome going on and this rewrite addressed a lot of that. It also sounds like they had a bunch of systems (probably different teams even) doing similar tasks like synchronizing state. And they also had their own UI framework. All that stuff adds up to a lot of code. But, all that being said, it still has a ton of features. It's not your father's IRC client sending text around and failing to transfer files through NAT/firewalls.
  - Turing_Machine 7y ago
    > But, all that being said, it still has a ton of features. It's not your father's IRC client sending text around and failing to transfer files through NAT/firewalls. Meh. It displays text, pictures, and videos. That's about it. This is just Messenger we're talking about here, not the full-blown Facebook app. The only state to keep track of is "Have you received message UUID?". > And they also had their own UI framework. This is where I suspect the bloat occurred. Writing your own JSON parser and so on doesn't add up to any 1.7 million lines of code.
    - ajconway 7y ago
      Well, browsers just display pictures and text, yet to build Chrome one needs to download gigabytes of code. Databases just keep an ordered list of records on disc. Compilers just look at the code and produce another code. Web servers only need to accept connections and respond with some data. Image editors are the simplest — they just let you paint with colored pixels.
    - ex3ndr 7y ago
      Dont underestimate complexity. For android you have to ship basically ffmpeg for correct mp4 encoding, on all platforms you have to carry some library on top of classical ui framework to make it just not suck at performance, you have to get your own json parser, yes, since built-in one will be 10x slower, you may be want to carry even low level QUIC library for networking and websockets, etc, etc. All this also not increasing complexity since built in one stuff makes your code much harder to read/write.
      - jcelerier 7y ago
        > For android you have to ship basically ffmpeg for correct mp4 encoding hopefully they aren't counting ffmpeg in their LOC count, right ? else they may as well count the lines of code of the C and C++ standard library, V8, etc - this would be a very useless metric

I've built a few "chat apps". I wouldn't discount the complexity. They carry with them a wide array of problem spaces. And of course anything at FB scale user counts is going to be a challenge.

Turing_Machine 7y ago

While I have absolutely no doubt there are scalability problems, it seems to me that most of those problems are going to be (or should be) on the back end, not in the client. How is the client 1.7 million lines of code?

jconley 7y ago
I can see it. It's pretty easy to hit that much code when you include your own code for things as trivial as a JSON parser rather than leveraging what the native SDK provides (which was alluded to in the article). It sounds like they had a bit of Not Invented Here syndrome going on and this rewrite addressed a lot of that. It also sounds like they had a bunch of systems (probably different teams even) doing similar tasks like synchronizing state. And they also had their own UI framework. All that stuff adds up to a lot of code. But, all that being said, it still has a ton of features. It's not your father's IRC client sending text around and failing to transfer files through NAT/firewalls.
- Turing_Machine 7y ago
  > But, all that being said, it still has a ton of features. It's not your father's IRC client sending text around and failing to transfer files through NAT/firewalls. Meh. It displays text, pictures, and videos. That's about it. This is just Messenger we're talking about here, not the full-blown Facebook app. The only state to keep track of is "Have you received message UUID?". > And they also had their own UI framework. This is where I suspect the bloat occurred. Writing your own JSON parser and so on doesn't add up to any 1.7 million lines of code.
  - ajconway 7y ago
    Well, browsers just display pictures and text, yet to build Chrome one needs to download gigabytes of code. Databases just keep an ordered list of records on disc. Compilers just look at the code and produce another code. Web servers only need to accept connections and respond with some data. Image editors are the simplest — they just let you paint with colored pixels.
  - ex3ndr 7y ago
    Dont underestimate complexity. For android you have to ship basically ffmpeg for correct mp4 encoding, on all platforms you have to carry some library on top of classical ui framework to make it just not suck at performance, you have to get your own json parser, yes, since built-in one will be 10x slower, you may be want to carry even low level QUIC library for networking and websockets, etc, etc. All this also not increasing complexity since built in one stuff makes your code much harder to read/write.
    - jcelerier 7y ago
      > For android you have to ship basically ffmpeg for correct mp4 encoding hopefully they aren't counting ffmpeg in their LOC count, right ? else they may as well count the lines of code of the C and C++ standard library, V8, etc - this would be a very useless metric