Live data from Hacker News

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

engineering.fb.com

291–300 of 333 posts

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

#291

Earlier quoted context omitted.

As far as I know messenger was never written in a cross-platform way, neither RN or otherwise. Is there anywhere that suggets it was ever non native?

It was fully native.

Not sure why people are downvoting an insider answer from an actual FB employee

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

#292
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

Exactly. But this was the last time the business collectively did something that short-sighted, right? Last time.

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

#293
post #219

Earlier quoted context omitted.

From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000." Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app. See also: this other comment - https://news.ycombinator.com/item?id=22468036

How in the name of everything did they manage to write 1.7M lines of code for a messenger app? That is an astonishingly large code base! We're talking about an instant messenger app with heaps of features, having a LoC footprint 3.5% of the size of modern Windows.

LOC is proportional to the number of engineers on a project. All engineers have to justify their existence, so, they will write code.

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

#294

Earlier quoted context omitted.

I wonder if react native library code and all the other code related to it like the js engine is included in that metrics.

There was no React Native in the Messenger app before the rewrite.

Oh my bad, i thought all facebook apps used react native

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

#295
The architecture they have ended up with is similar to that described in Out of the Tar Pit, which describes how to remove as much complexity from software as possible.

By moving all state into SQLite they have implemented the "store state in relations" layer, and then written (as far as possible) functional code on top.

I've been thinking about how to make my software more like this so it's interesting to see Facebook are thinking along the same lines.

There's a lot of really good ideas in Out of the Tar Pit and I'd really recommend reading it.

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

#296
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

You do realize that you can have one code base and write in C++ right? You don't need a slow framework to have a UI run in multiple places.

Somehow younger generations are allergic to it, you seldom see it listed as alternative for portable busines code, even though it is available out of the box in all mobile SDKs, with first class IDE support alongside the respective upper layer languages on the platforms.

And the amount of time spend writing a bit of glue code, specially on Android, is still less than debugging integration issues in all those Hybrid/Abstration frameworks.

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

#297

Earlier quoted context omitted.

Well, they now have a single-platform application without all the platform-shared code. It's not like there's no tradeoff.

But look a bit further, it gets better ... > For any cross-platform logic, we used an operating extension built in native C code, which is highly portable, efficient, and fast. We use this extension for anything OS-like that’s globally suboptimal, or anything that’s not covered by the OS. For example, all the Facebook-specific networking is done in C on our extension. C was the universal donor 30 years ago, and it's…

And then there are those ignorant of the 10 years of systems programming that preceded the inventation of C, and how the computing world looked like at Xerox PARC, IBM, DEC, Wang, Olivetti,....

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

#298

Earlier quoted context omitted.

How in the name of everything did they manage to write 1.7M lines of code for a messenger app? That is an astonishingly large code base! We're talking about an instant messenger app with heaps of features, having a LoC footprint 3.5% of the size of modern Windows.

> Since then, we’ve added payments, camera effects, Stories, GIFs, and even video chat capabilities Simple: they added tons of crap nobody care. On this list, I only use video. Messenger is valuable because of the network effect, but feature wise 2003’s MSN was good enough.

> nobody care

> _I_ only use

(emphasis added)

Just because you don't use those features, doesn't mean nobody cares about them

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

#299
post #230

Earlier quoted context omitted.

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

If FB Messenger beat Whatsapp they wouldn’t have had to buy it.

Facebook bought Whatsapp for the social graph, not the messenger technology

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

#300
post #247

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.

You don’t need 1.7m LOC to build a simple app that works well over different network conditions. Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.

> You don’t need 1.7m LOC to build a simple app that works well over different network conditions.

Also known as:

You can do dropbox with FTP.

If Friday is Feb 28th, then Monday is March 3rd. There's no need for those bloated date libraries.

> Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.

Certainly. It worked before the change. So it is given that 1.7m of "garbage" provided a working product.

How many lines of code it took Google to make Hangout not get confused by image uploads on crappy connections? Unknown, because it is still confused.

How many lines of code it took Signal not to delay messages when a recipient is on a crappy connection? Unknown, because it still does that.

Post reply on HN