Live data from Hacker News

Tempted to Abandon React Native for Native Android

kelvinpompey.me

31–40 of 63 posts

Re: Tempted to Abandon React Native for Native Android

#31
I've done some work with react native, and have definitely been disappointed by the poor quality of many third party libraries that are not supported by Facebook.

This is a big opportunity for those who might wish to make a name for themselves by developing some top quality open source components, but I also think Facebook should do a bit more to make using the phone's core features in a very high quality way as easy as possible. Things like the camera, audio recording, video, etc., are handled only via third party libraries.

The third party open source work is improving, and I'm grateful it exists, but much of it lacks contributors. Many have large lists of unresolved issues on github.

It would be very smart choice for Facebook to put a dozen or so developers on the task of submitting high quality PRs for the top 20 open source non-facebook libraries.

Re: Tempted to Abandon React Native for Native Android

#33

My next foray into mobile is going to be with this- https://www.nativescript.org/ Digging through the api it just looks much more capable in directly calling android instead of abstracted cross platform blobs.

The NativeScript site says that I can use their cross-platform wrappers like Button, which delegates to UIButton on iOS and android.whatever.Button on Android. So far, so good. But suppose I now want to invoke some method on Button that exists only on iOS. Can I do that? If not, it's the least-common-denominator, which I'm not interested in using to build an app. I'm thinking about something like:

var button = new Button(...);

// Set the common properties:

button.backgroundColor = ...;

button.text = ...;

if (iOS) {

  // Set iOS-specific properties
} else {

  // Set Android-specific properties

}

Re: Tempted to Abandon React Native for Native Android

#34

Earlier quoted context omitted.

Fresco is extremely notorious for causing crashes, I had no idea React Native used it. Picasso and Glide are the two sensible choices for image loading. Facebook's tools for Android are generally written in a way that you get the feeling one could only justify by repeating the manta "We're Facebook, these are Facebook scale problems" the whole time writing you're them. (see: Redex vs just Proguard) Wether they 're pr…

Redex does tons of things Proguard doesn't, and it operates on Android's native Java-program format, dex files, not java class files like Proguard. What's the problem?

It's diminishing returns, it breaks in many more ways than Proguard with minimal benefit. I truly question if focusing the engineering effort on reducing bloat in their app won't have saved more space than Redex.

Re: Tempted to Abandon React Native for Native Android

#35
I searched for the holy grail of cross-platform goodness like a fool for years. I now have my first native UI android application on google play and I don't regret the decision. I made a prototype and then optimized it in ways I wasn't able to do in html or react-native. (try downloading and caching pictures rendered in a listview asynchronously while keeping the scroll smooth)

I now don't have an iOS version, but in my opinion having a finished product that is already gaining traction makes up for the lost time of learning to make the same thing for iOS.

Re: Tempted to Abandon React Native for Native Android

#36

It'd be nice with React Native was actually "native" and not just a JS interpreter (really not that much different than HTML5 running in a browser). No wonder there are performance issues.

With ReactNative, the controls are all native, JavaScript is just there for orchestration, so it is far different than HTML 5, given the browser doesn't give you the same array of native components to use.

Re: Tempted to Abandon React Native for Native Android

#37

I searched for the holy grail of cross-platform goodness like a fool for years. I now have my first native UI android application on google play and I don't regret the decision. I made a prototype and then optimized it in ways I wasn't able to do in html or react-native. (try downloading and caching pictures rendered in a listview asynchronously while keeping the scroll smooth) I now don't have an iOS version, but in…

Have you tried FuseTools? https://www.fusetools.com

Re: Tempted to Abandon React Native for Native Android

#38

My next foray into mobile is going to be with this- https://www.nativescript.org/ Digging through the api it just looks much more capable in directly calling android instead of abstracted cross platform blobs.

I am using FuseTools which is OpenGl. Everything compiles down to C++ or objective C and JavaScript. https://www.fusetools.com/

Re: Tempted to Abandon React Native for Native Android

#39
post #2

Sounds like a good opportunity to build some performance-tuning muscle :) Whether using RN or java, you'll want to know how to debug memory/performance issues on Android - they're mostly unavoidable on mobile devices! (And maybe you can file some issues against React Native, too, which would be great and help the platform)

That's a fair point about the opportunity to build some performance-tuning muscle but I imagine to do that would require solid knowledge of both React and Android. Where do I start? I am more inclined to go towards the native Android side first. Aa a follow up, I just did a test with a native Android app doing the same thing: getting an image through an Intent. With the native Android app, the same image that was cra…

Are you sending an image bitmap in the actual Intent? I'm surprised you're not having it break when sent to Android's IPC mechanism which has fairly low size limits.

I would use a Content Provider to share the image instead.

Re: Tempted to Abandon React Native for Native Android

#40
post #17

Earlier quoted context omitted.

I analysed react-native's performance issues with images and out-of-memory-errors a while back. Their (and their image library Fresco's) problem is that they make heavy use of object-finalizers, which is an error in Java and especially Android. I reported a couple of bugs, but got dismissed: https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8780 https://github.com/fa…

Fresco is extremely notorious for causing crashes, I had no idea React Native used it. Picasso and Glide are the two sensible choices for image loading. Facebook's tools for Android are generally written in a way that you get the feeling one could only justify by repeating the manta "We're Facebook, these are Facebook scale problems" the whole time writing you're them. (see: Redex vs just Proguard) Wether they 're pr…

They're suffering from not-invented-here-syndrome.

Also while custom memory management made sense for Android 2.2, they should have just thrown it out after 3.0.

But giving up code isn't easy.

Post reply on HN