So it's basically MVVM with SQLite as the model?
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
61–70 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#62From: https://engineering.fb.com/data-infrastructure/messenger/ > We accomplished this by using the native OS wherever possible Does this mean this application does not use React Native?
-step 1 : write an app with a multiplatform framework.
-step 2 : rewrite it in native so you greatly improve metrics while reducing code base size.
Seems like a good way to achieve great improvements in your product
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#63This is an interesting business decision. To rewrite such a large app must have cost a fortune. Going full native is probably going to increase the cost of future development as well. Aside from the costs of writing/maintaining the code, pushing more work to the servers is an ongoing cost. Realtime, always-connected, apps are costly to run even when you push the majority of the state management to the client and just route packets around. They must really want eyeballs in their messenger app! There must be some future plans for this app that warranted such a major effort. Taking on Tik-Tok, perhaps?
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#64Just downloaded the latest update on my iPhone XR. Does seem a lot more snappy and I'm loving the recent UI/UX changes too, especially the sending photos & GIF changes.
Good work Facebook!
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#65It'll suck for the SEO team at LightSpeed point of sale company. FB named a open source project the same name as a company.
I don't know if it's clear it will suck? You just advertised their company, it's the first time I ever heard of them. It's not like LightSpeed is an unheard of name? It's a stock trader, web filter, data warehousing company, and probably a million other things. Novel names are hard to come by.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#66From https://engineering.fb.com/data-infrastructure/messenger/ : Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used qui…
They make it sound like the clouds parted and a ray of sunshine struck the programmers at Facebook and they realized that they didn't have to ride the framework-go-round to hell.
These are supposed to be the smartest people in SV, but from the outside, it strikes me more as a "No shit, Sherlock" moment.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#67From: https://engineering.fb.com/data-infrastructure/messenger/ > We accomplished this by using the native OS wherever possible Does this mean this application does not use React Native?
-step 1 : write an app with a multiplatform framework. -step 2 : rewrite it in native so you greatly improve metrics while reducing code base size. Seems like a good way to achieve great improvements in your product
If the step 1 allows you to get your product out more quickly and that has enough business value, I don't see why not
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#68Too little and too late. I feel like they lost a whole generation of people.
Depends, if they allow WhatsApp and Facebook to intercommunicate through it, then they could get 100M people using it by next week.
I'm not quite sure why I need two apps on my phone for communications through one company when 12 years ago I had one app on my desktop for 5 or 6 different company's messaging services.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#69This is an interesting business decision. To rewrite such a large app must have cost a fortune. Going full native is probably going to increase the cost of future development as well. Aside from the costs of writing/maintaining the code, pushing more work to the servers is an ongoing cost. Realtime, always-connected, apps are costly to run even when you push the majority of the state management to the client and just…
> To rewrite such a large app must have cost a fortune. Going full native is probably going to increase the cost of future development as well.
it's a freakin chat app, and it's freaking facebook ! come on, people were doing full rewrites in entirely different languages of software insanely more complex than fb messenger back in the 90s and with near-zero tooling, eg from cobol to pascal to C or similar horrors.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#70Earlier quoted context omitted.
I really wish iOS would allow you to select which contacts/photo album to give an app access to, instead of all hundreds/thousands of them.
For photos, I wish iOS would not require a permission at all in the case where I just want it to open an OS-controlled file picker and then give the app the one photo, akin to copy-pasting it. No reason to give access to every photo when only N are picked.
It’s been a while since I worked with the photo library APIs in iOS, but as I recall there in fact is an API that apps can use to request the user to pick individual photos from an OS picker without further permissions. Most apps just don’t use it because they all want to do their own custom photo picker UIs (even privacy focused apps fall victim to this).