Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

engineering.fb.com

Post reply on HN
Print view View original

301–310 of 333 posts

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

#301

Post by pjmlp »

tomduncalf wrote: post #287
danabramov wrote: post #280

Earlier quoted context omitted.

To be clear, Messenger wasn’t being rewritten from React Native. It was a fully native app before, too.

Yeah, not sure where this idea has come from. Seems like RN haters just jumping on any opportunity to slate it. Reality is, just like most technologies, RN is a good fit for some scenarios (small team needing to support both mobile platforms? no native devs on the team? performance not critical? etc.) and not a good fit for others. I guess many native developers feel negatively towards it because a lot of companies w…

Thing is, all these frameworks are leaky, to debug anything on them, or to add missing functionally, that small team needs to be an expert across two native frameworks, and the hybrid/abstraction framework that they are betting on.

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

#302

Post by kuschku »

notyourday wrote: post #97
aldanor wrote: 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'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.

That's a joke, right? On a crappy internet connection (e.g. using O2 as carrier on the train cologne-hamburg you get ~12s ping, 30kbps, >90% packets dropped, via edge) most chat apps stop working, but Facebook Messenger is (except for Riot.im and Discord) probably the one that works worst.

Telegram works better, even IRC via Quassel/Quasseldroid works significantly better, and especially WhatsApp works so well you don't even notice the connection issues.

Facebook Messenger doesn't even properly start on such crappy connections.

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

#303

Post by ajscanlan »

monocasa wrote: post #13
Doctor_Fegg wrote: post #5

Here's a way in which they can save 100% of the size: Stop stubbornly barring mobile clients from using the web interface. This is why I don't use Facebook Messenger at all.

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

The apps don't have permission to do that either unless you grant them.

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

#304

Post by Ayc0 »

hvidgaard wrote: post #262
tasogare wrote: post #257

Earlier quoted context omitted.

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

None of that justifies 1.7 million LoC.

That's not true, the application, whether you like or not, it full of micro-interactions, well-done animations and transitions, features like the payment or stories, you can take photos directly from the app, etc.

With that many features, it doesn't surprise me that the previous codebase was 1.7M LoC. Sure if you count only the messaging part, I'm fairly certain that the LoC is way lower than this.

It doesn't make sense to compare the number of LoC of messenger to the number of LoC of software like Postgres because Postgres tries to be good at 1 thing and messenger tries to have a ton of features with good UI and UX.

I don't like many of their features (I'm not using the stories or the payment), but some of my friends do and you have to recognize the work that the messenger team did to make them work that well.

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

#305

Post by FunnyLookinHat »

hvidgaard wrote: post #246
fao_ wrote: 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.

I had the same question... And that's not counting LOC on the server. And all of this is for... glorified text messaging, right? I don't use FB so I could be missing context or features.

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

#306

Post by lvh »

notyourday wrote: post #208
ComputerGuru wrote: post #197

Earlier quoted context omitted.

I have, with an OpenVPN-over-UDP tunnel as a workaround. If they included Wireguard (or better yet, just used encrypted UDP) it would still be smaller (and probably more reliable).

Introduce random dropouts, crazy jitter and random IP switches and you get the emulation of what a crappy network looks like.

I don't know if this is what you were referring to, but for everyone else: this is actually super easy to add with Wireguard because Wireguard just uses Linux networking you can do things like:

  $ tc qdisc change dev eth0 root netem loss 0.3% 25%
(Lose 0.3% packets on average, but each packet is 25% correlated with the last packet loss, to produce bursts.)

  $ tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
(Add mu=100ms, sigma=20ms normally distributed latency.)

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

#307

Post by tomduncalf »

pjmlp wrote: post #301
tomduncalf wrote: post #287

Earlier quoted context omitted.

Yeah, not sure where this idea has come from. Seems like RN haters just jumping on any opportunity to slate it. Reality is, just like most technologies, RN is a good fit for some scenarios (small team needing to support both mobile platforms? no native devs on the team? performance not critical? etc.) and not a good fit for others. I guess many native developers feel negatively towards it because a lot of companies w…

Thing is, all these frameworks are leaky, to debug anything on them, or to add missing functionally, that small team needs to be an expert across two native frameworks, and the hybrid/abstraction framework that they are betting on.

Yes and no, I think that depends how deep you want to go. For your standard "show and update some content and make it look pretty" type app, I can tell you from both my own and others experience you don't really need much familiarity with the native platforms, other than how to use build tools etc. which are well detailed online.

If you want to go deeper or have more specialised requirements, then you might need a deeper understanding of the native platforms though.

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

#308

Post by moron4hire »

pests wrote: post #220
moron4hire wrote: post #95

Earlier quoted context omitted.

I have a set of code I use for my VR projects that I've been iterating on over the last five or so years. It includes a ton of not-VR stuff, too, just stuff that I tend to include in my projects. (aside: and I'm not trying to make it a "framework". It's just my own code and it's only publicly available in the sense that I don't charge for it, don't want to waste a private Github repo on it, and won't stop anyone from…

For what it's worth, GitHub private repos are now free so you don't have to sorry about wasting one.

Yes, I know, but I do also occasionally share code snippets out of it. If someone in a chatroom is asking how to do X, I'll just link to a source block in my repo. It's lazier than copy-pasting the code, but I also think it's good to let people see the broader context, maybe explore on their own a little.

I wouldn't mind if other people started using the code, but I've been burnt too many times during attempts to push my OSS projects over the years that I just don't want to put any actual effort into attracting people anymore.

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

#309

Post by flucivja »

fao_ wrote: post #219
butz wrote: 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

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

I'am curious if in 360K LOC are also included templates configurations stored in SQLite because these must be written and maintained too.

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

#310

Post by ksec »

pjmlp wrote: post #296
BubRoss wrote: post #215

Earlier quoted context omitted.

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/A…

>Somehow younger generations are allergic to it,

Because they haven't been burned by that cycle yet.

Post reply on HN