Live data from Hacker News

LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

engineering.fb.com

141–150 of 333 posts

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#141

Earlier quoted context omitted.

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?

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 t…

> 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.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#142
post #120
post #109

Earlier quoted context omitted.

Honestly, a chat app that 1 billion+ use per month that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat, and works across all mobile platforms, with nine years of technical debt, that thousands of developers build simultaneously seems WAY more complicated to me than any of your examples. Messenger may not have "HN clout" bu…

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat To be fair, this is part of the problem ^

It's an inner-platform effect, certainly, but not one FB asked for. If they were allowed by the app-stores to factor their app into separate "plugins" that were auto-installed when a friend used them in a chat, the way iMessage does, they'd probably do that. But they're not allowed to have their own seamless plugin ecosystem, so into the monolith everything goes.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#143
post #50

Earlier quoted context omitted.

But then they don't have permissions to slurp up all of your contacts, watch all of your SMS, and listen to your microphone...

Wait! Somebody found evidence of them listening to your microphone?

Still no. If an iOS app is using your microphone while backgrounded, your phone's taskbar at the top of the screen will be red. iOS does not allow apps to use the microphone while the screen is off. The microphone thing is a myth fueled by paranoia and confirmation bias. FB already has plenty of data on you and doesn't need to run NLP on everything you say in order to show you relevant ads.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#144

Earlier quoted context omitted.

It's probably not meant for us, but instead the third world phones where they've gotten to the point that it might not even install on a large part of their user base. Like I've heard from peace corps folk about how a large part of the third world thinks of messenger as "the internet", which is absolutely terrifying.

As someone with a modern smartphone I'm a huge fan of these lite apps. Spotify lite, for example, has all the features, a better (!) UI (with material ripples) and everything loads about twice as fast. Every app should be a lite app. Devs, please start giving a shit about performance.

I've tried FB lite, and found it to be slower than the real app. FB lite seems to act like a fancy web browser, so each interaction needs to download it's UI along with content.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#145

Earlier quoted context omitted.

It's a chat app that works very well even on the crappiest connections. If it having 1.7M lines of code indicates anything it is that creating a "simple app that provides simple functionality over a network well" is hard . Look at the garbage generated by Google - text messages and images on Google hangout are not guaranteed to arrive in order ( or even be sent in order ) unless you are on a great network.

> It's a chat app that works very well even on the crappiest connections Does it? I routinely use Telegram, Line and Messenger. Messenger is without contest the one that gives the most trouble. I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined. That being said, I'm sure that a lot of progress have been made and that there's a lot going on behind Messenger in ter…

> I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined.

You never used ICQ over a spotty 3G connection, though, did you?

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#146
post #85

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment: - NumPy is 360K lines mostly C - Postgres is around 2.1M of C - Go 1.13 is around 1.5M of Go code - Rust 1.37 is around 1.2M of Rust code iirc - core llvm is around 3M of C++ iirc ... A chat app is 1.7M. A chat app... Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've…

it seem you don't have experience on large scale apps... and the people that make these type of comments almost never have had to work on large applications.....

Spotify had about 500k, lines of code in 2015, (not including external libraries).

We did make it in a feature based architecture, where there was a main container app (and a major core playback library) and for every major feature they had their own sub-project.... and there were 10+ teams contributing into it.

There were about 13 features at the beginning, (think, playlists, radio, shared ui libraries, etc...).

Each feature was about 10-20k lines of code in total. So, about 2-3 features equal a small standalone iOS app.

When I left, there were more than 80 features in the app. Some were essential, many were a/b tests, and some were probably just legacy/waiting to be removed.

80 features * 15k lines of code = 1.2mil loc, easily, and they are the equivalent of shipping 20 small apps standalone....

What are these features and why is just a stupid music app so large? : video, podcasts/shows, genius, etc.. etc.. etc.... To users just looks like another tab but almost every one of these major features could be its own standalone app for size and complexity.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#147
post #76

The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2

1. Developers: YEP! 2. Developers: YEP! 3. Developers: YEP!

Munch Munch Code Munch WTF Munch AGILE! $$$ Munch.

Designers: 1. We need a new design system. 2. We need a new brand! 3. We need a new font!

Users: ¯\_(ツ)_/¯

/s <3

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#148

Earlier quoted context omitted.

Ordering messages and providing reliability does not require 1.7M lines of code.

Code wins arguments. FB messenger beats everything, Whatsapp, Wire, Signal, WeChat, Telegram included, in the suckiest network connections.

Repeating a point without adding proof doesn't make your point more valid. When people say "code wins arguments", they're referring to using source code to prove something, not "it wins because it has more source code" (???).

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#150
post #136
post #18

Not sure how much impact this will have, most of the people I know and have discussed this with fall into two camps: people who use FB a lot an will put up with a bad mobile client, and people who don't want FB on their phone, ever. I have to go years back to think of someone who told me they just couldn't take the bad UX of the clients so they deleted it.

For a while, before it really started to bloat, FB Messenger was the slickest, most well-rounded, most enjoyable messaging client I could find, and had the advantage that all of your friends were already on it. The bloating from Stories and everything happened to coincide with my ejection of all things Facebook from my life, but Messenger was a genuinely good product at one point. Sounds like it may be returning to t…

Yep. In my high school and college days (2008-2016) Facebook Messenger was the way that you chatted with other people.
Post reply on HN