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.

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 will be asking "why aren't we using React Native instead of building two separate apps?" which I can imagine feeling somewhat threatening towards your area of specialisation

> Yeah, not sure where this idea has come from. Seems like RN haters just jumping on any opportunity to slate it.

There seems to be a much more obvious explanation as to why people are assuming it used to be React Native. The article says:

> > Compared with the previous iOS version, this new Messenger is [mentions improvements].

> > We accomplished this by using the native OS wherever possible […]

That seems to imply that it wasn't native before and they got the gains by switching to native. And since Facebook are well-known as the creators and biggest users of React Native, it's not a big leap to make the assumption that that's where they were coming from.

[Also, in case there's any confusion please note the distinction between "native", meaning it is compiled to native code; and "React Native", which is a cross-platform framework that is not compiled to native code. "React Native" is a horrible name for something that is not native.]

My bad, I didn’t pick up on that wording potentially suggesting that. RN gets quite a lot of flak from native devs it would seem, hence my assumption!

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.

I can speak for Qt, Ionic and Cordova.

Beyond "Hello World" all of them required me to get my hands dirty, at which point I was better off just doing C++ with native views, standard out of the box tooling available across all SDKs.

Nowadays I rather go for PWAs, or plain mobile Web, unless it is something very special that requires OS APIs or hardware access.

I've worked power-user type applications that are mainly keyboard driven, and those are pretty easy to make cross platform with a single custom codebase that has a platform-specific graphics backend (OpenGL covers many platforms) and minimal platform code. Let's say < 300 lines of boilerplate per platform + 600 lines for OpenGL + 2-5K lines for (shared) UI controls.

Yeah, but that kind of fits what I was describing, you are using standard SDK tooling, and it looks to me it being game engine like.

I wasn't disagreeing.

Neither was I. :)

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.

Interestingly, there was news on some satellite running javascript. But I wonder if the core was running something else, and peripherals were run with js -- and simply restarted when they died, Erlang style.

> Interestingly, there was news on some satellite running javascript.

It does not mean it runs JS for anything critical, and very likely it does not.

My car entertainment system (GUI) run JS, and I'm fine with it. I would not if it would run on the emergency breaking system...

JS requires a runtime, so by definition there would have to be something (even if it’s just a bastardized gc-free version of JS itself).

Technically so do the native platform frameworks: they just come with the system.

Exactly. The point of using a cross platform solution is because you can't afford to make an app for each platform.

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.

I don’t think Facebook Messenger ever used React Native

And then seeing the rest of the defenders slink back to the shadows. Until the next framework hype cycle comes along...

Messenger was never written in React Native https://reactnative.dev/showcase

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

-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

That's fair and there is definitely a use case for these frameworks in order to quickly ship a product on several platforms.

There is also an inherent cost to rewriting all your codebase at once that should not be under estimated.

For something so big and integrated as messaging, I am not sure that this was a good match.

Admittedly turning messaging into a do all à la WeChat was very probably part of the initial plan.

They definitely wouldn't be able to achieve these kinds of results with React Native. It obviously adds a lot of unnecessary overehad.

I can't decide if seeing the pendulum swing that drastically would be hilarious to see, or not.

> We also embraced platform-dependent UI and associated tooling

It would seem that way.

There's no mention either way. The article talks about a single C library and C extensions. And it mentions using native OS functionality. Those could be used from javascript or any language.

Yeah, which is probably why it's in C, portable AND callable :)

The place that invented it not using it would be huge

Did the previous application use React Native?

When I interned at FB in 2018, there was no RN in the Messenger codebase. However, it did make extensive use of various FB UI abstractions like Yoga layout and ComponentKit.

I'm thinking maybe they moved off of React Native. RN makes sense for a small org or for an app you're just getting started with, but a megacorp like FB can afford to hand-craft a smaller, tighter app for each platform.

Wow! So the OS frameworks are there for a reason? Who would have thought?!

Mind = blown!

One can only hope that Slack and other Electron apps reach this point eventually...

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.

Ah, you're correct - not sure why I thought otherwise, especially when I touch WKWebView pretty often.

Perhaps you confused it with JavaScriptCore?

Hmmm, possibly. Either way thanks for the catch!

Printing still sucked pretty bad in WKWebView the last time I looked into it (which admittedly has been a year or two, so maybe that's been fixed).

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

React-native does not run in a webview. The JS binds directly to native elements. In fact, you can easily wrap any native code and make JS bindings to call it directly.

React Native doesn't use a webview.