From: 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?
Did the previous application use React Native?
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
71–80 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#72From 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.
Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#73From: 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?
React Native isn't necessarily a great fit for something that is intended to be "a simple, lightweight utility" - there is a reasonable start up overhead, for example, with RN, and it also involves bundling quite a few libraries and dependencies.
That doesn't mean React Native is not a good fit for any kind of application - for many kinds of apps, start up time and app size are a much smaller issue - but seems Facebook made the right decision for an app like Messenger which primarily needs to start fast and drain as few resources as possible.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#74It'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.
[deleted]
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#75> We extended SQLite with the capability of stored procedures, allowing Messenger feature developers to write portable, database-oriented business logic
I wish the article was a little more fleshed out, I'd be interested in finding out more about how and why they went down this path
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#76The 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
#77RIP React Native
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#78From: 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.
> Given the headaches caused by Apple finally barring UIWebView (the basis of frameworks like Cordova)
Cordova (and derivatives, such as Ionic) have had WKWebView available for a long time now, I think since iOS 9.
The Cordova team added a compile-time flag to force WKWebView in 5.1.0 (out since last November), and will be removing UIWebView altogether in 6.0.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#79Earlier quoted context omitted.
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.
Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?
“I was instrumental in making Messenger twice as fast?”
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#80From: 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?
React Native isn't necessarily a great fit for something that is intended to be "a simple, lightweight utility" - there is a reasonable start up overhead, for example, with RN, and it also involves bundling quite a few libraries and dependencies. That doesn't mean React Native is not a good fit for any kind of application - for many kinds of apps, start up time and app size are a much smaller issue - but seems Facebo…
React Native (or any framework) isn’t good when you can literally afford billions of dollars of R&D given the financial value of the app. Just like the Mars rovers don’t run Python but it is a great language for a experimental SaaS app testing a new market, RN is great for a team of 3 engineers to get a multi platform app shipped, but not a great choice for an app worth ~$100 billion to its parent company.