how does one manage to make a chat app bloated in 2020?
Abstraction craze. React Native etc etc.
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
41–50 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#42Not 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.
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.
Hadn't thought of that - good point.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#43Assuming one hates notifications, is there _any_ reason why anyone would want to use app over m(basic[1]).facebook.com?
[1] to access messenger because fb stubbornly thinks I want to install their crap/spyware on my phone
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#44Here'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.
If I request the desktop site, I am able to access Messenger (iOS, Safari)
That’s a workaround for a on purpose decision to cripple the mobile website, where the chat and messages worked flawlessly. Another decision against users was to use messages as notification in some cases.
I didn’t pull the trigger on canceling the account as from time to time I find news and event from pages that I follow, but there’s no way I’m installing an app that uses so many shady tactics.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#45From: 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?
Man, I hope so. There has beens so much cargo cult built up around React Native that suggesting other approaches is almost guaranteed to kick off many rounds of contentious design meetings.
Fortunately, nothing quite takes the wind out of a platform's sails like watching the creator back away from the platform.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#46From: 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?
(Some of the comments in this thread, like this one, were originally posted to https://news.ycombinator.com/item?id=22467769, which explains e.g. why they mention the URL explicitly.)
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#47From: 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?
Yeah, that's how I am reading that. Given the headaches caused by Apple finally barring UIWebView (the basis of frameworks like Cordova) from new App Store submissions beginning in April, I'm not surprised FB would do this. There is plenty of rumor-mongering that Apple is going to make it increasingly difficult for apps based on hybrid frameworks through the submission process.
UIWebView was deprecated for years, everyone's had plenty of time to move to WKWebView, and it has nothing to do with React Native to boot.
Apple legitimately doesn't seem to care about hybrid frameworks, they've been there since day one. Any time it's seemed like it got difficult Apple has backed down. The lack of JIT in WKWebView is probably the only thing that you could stretch here.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#48Assuming one hates notifications, is there _any_ reason why anyone would want to use app over m(basic[1]).facebook.com? [1] to access messenger because fb stubbornly thinks I want to install their crap/spyware on my phone
I think some things do not show up on the mobile pages - reactions and polls, I believe - maybe stickers? I'd also have to check if replies show up correctly
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#49Earlier quoted context omitted.
Yeah, that's how I am reading that. Given the headaches caused by Apple finally barring UIWebView (the basis of frameworks like Cordova) from new App Store submissions beginning in April, I'm not surprised FB would do this. There is plenty of rumor-mongering that Apple is going to make it increasingly difficult for apps based on hybrid frameworks through the submission process.
UIWebView was deprecated for years, everyone's had plenty of time to move to WKWebView, and it has nothing to do with React Native to boot. Apple legitimately doesn't seem to care about hybrid frameworks, they've been there since day one. Any time it's seemed like it got difficult Apple has backed down. The lack of JIT in WKWebView is probably the only thing that you could stretch here.
WKWebView is out-of-process and has a JIT.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#50Here'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...
Wait! Somebody found evidence of them listening to your microphone?