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.
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
291–300 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#292The 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
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#293Earlier 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.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#294Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#295By 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
#296The 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.
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
#297Earlier 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…
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#298Earlier 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.
> _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
#299Earlier 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.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#300Earlier 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.
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.