Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tempted to Abandon React Native for Native Android

kelvinpompey.me

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Tempted to Abandon React Native for Native Android

#41

Post by Hydraulix989 »

ec109685 wrote: post #36
Hydraulix989 wrote: post #32

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.

That's less accurate than my original post, especially given I was commenting on the performance trade-offs of RN's architecture. I highly recommend watching this official video about the internals in order to gain more of an understanding:

https://www.youtube.com/watch?v=8N4f4h6SThc

In short, there aren't too many interpreted languages that don't rely on "native bridges" for things like UI and access to system libraries, but I wouldn't call desktop GUI frameworks for non-native languages like Java Swing or C# WinForms "native" even though they also use what you call "native components."

On the other hand, I would consider iOS Objective-C/Swift, Android NDK, and MFC/QT/GTK+ in compiled languages like C++, Rust, etc. to be truly "native" (but not Android Java, of course).

React "Native" is still very much interpreted code (if anything, RN is a different kind of "browser" that runs JS code -- yes, the JS that runs in browsers still has the same "orchestration" role that you've described from an architecture standpoint).

Re: Tempted to Abandon React Native for Native Android

#42

Post by indy »

BoorishBears wrote: post #34
quotemstr wrote: post #30

Earlier quoted context omitted.

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.

"it breaks in many more ways than Proguard" is a phrase I thought I'd never hear

Re: Tempted to Abandon React Native for Native Android

#43

Post by mercer »

EGreg wrote: post #29

What do you all think of Cordova? Do the author's comments apply there also? Does it crash from using too much memory after a while of loading objects? And does it make things not work on older devices and platforms making it a dealbreaker for anyone?

My recent experience with Cordova has been much better than I expected. It's quite a bit easier to work with than I thought, and the performance is fine for the relatively 'standard' UI and animations/transitions I needed. And with a few specific tweaks I could even make it seem pretty native (momentum scrolling, etc.).

All that said, I'd still recommend going native or React Native if 1) you can afford it (time/money/properly skilled employee), or if 2) the app's needs are beyond what a 'typical' in-browser web app does.

In regards to the latter I've found quite a number of plugins that let you do notifications, or use the accelerometer, but on the whole I've found that cordova plugins can be finicky. Plus, the more plugins I need to add and the more native functionality I need to use, the more nervous I get about not fully grasping the underlying stuff.

Basically, I used to think Cordova was never really an acceptable option, especially with the release of React Native. Now, I think there are plenty of situations where it's the best solution for a client.

Re: Tempted to Abandon React Native for Native Android

#44

Post by jon-wood »

EGreg wrote: post #29

What do you all think of Cordova? Do the author's comments apply there also? Does it crash from using too much memory after a while of loading objects? And does it make things not work on older devices and platforms making it a dealbreaker for anyone?

I haven't used Cordova recently, but when I last did a couple of years ago I had similar problems with image handling resulting in memory running out on low spec devices. From the comments I've read here probably for similar reasons as well, the camera capture API was passing a Base64 encoded image to the application rather than a file URL.

Re: Tempted to Abandon React Native for Native Android

#45

Post by 2sk21 »

ec109685 wrote: post #36
Hydraulix989 wrote: post #32

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.

I haven't been following React closely but this reminded me of a package called SWT that is used as the underpinning for Eclipse (https://www.eclipse.org/swt/). In the case of SWT, the underlying widgets are platform native but the orchestration is in Java. SWT was used to build a few desktop apps but mostly it seems to have been forgotten now. It left me skeptical of these kinds of thin UI layers.

Re: Tempted to Abandon React Native for Native Android

#46

Post by menckenjr »

nurettin wrote: post #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…

There really is no such thing as a free lunch. If you want to skip having to learn the native platforms, you're going to have to put up with your app having at least one giant external dependency in it.

(Native iOS app developer here, dabbled in React Native and went "nope" as soon as I saw how it worked and how heavily it depended on 3rd party components.)

Re: Tempted to Abandon React Native for Native Android

#47

Post by Matthias247 »

cageface wrote: post #25
htormey wrote: post #15

Earlier quoted context omitted.

Yep, exactly my experience. I love React Native but if your not used to the Javascript style of million's dependencies your in for a world of pain. It's critical to spend more time vetting third party React Native/Javascript libraries as the quality level varies way more than with native libraries. As a native developer I hadn't spent a lot of time working deeply with npm. One thing to be careful about when saving pa…

I recommend pinning to exact versions and using a tool like npm-check-updates when you want to upgrade to newer versions of libraries. We had a lot of problems with breakage due to different developers having slightly different versions of dependencies. React Native is a great platform but it's still very fragile, particularly on Android.

I recommend that too. I only used the npm ecosystem for a short time, and still had dozens of silent breakages from libraries which were expected to update in a backward compatible fashion. And even if a dependency itself is pinned to an exact version, it might be that the transitive dependency of this thing changes and breaks. npm shrinkwrap and yarn are supposed to fix that.

Re: Tempted to Abandon React Native for Native Android

#48

Post by menckenjr »

t1amat wrote: post #13

I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though. This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painles…

All due respect, it isn't really the same code base at all. RN assembles your app from a large list of components based on what your JSX file tells it needs to be imported. If you went and counted LOC you'd probably find that most of the lines of code (outside of the RN backbone) live in those modules. The common code you can share is your JSX.

Re: Tempted to Abandon React Native for Native Android

#49

Post by t1amat »

menckenjr wrote: post #48
t1amat wrote: post #13

I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though. This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painles…

All due respect, it isn't really the same code base at all. RN assembles your app from a large list of components based on what your JSX file tells it needs to be imported. If you went and counted LOC you'd probably find that most of the lines of code (outside of the RN backbone) live in those modules. The common code you can share is your JSX.

While technically correct it's not very meaningful a distinction in context. I'm not tasked with developing all the code required for every platform, I simply have to describe it once. Native platforms will all run off the exact same JavaScript bundle in a different, platform-specific shell. You wind up with a different bundle if you target the web.

Re: Tempted to Abandon React Native for Native Android

#50

Post by t1amat »

hammerandtongs wrote: post #14
t1amat wrote: post #8

Earlier quoted context omitted.

For the types of problems the author is describing, NativeScript would not be there to support you. NativeScript surfaces the device API's across the JS bridge, and the serialization across this bridge and pressure on it will always lead to less performant code. You would have to drop to native modules all the same, and then what have you solved?

https://docs.nativescript.org/runtimes/android/advanced-topi... Perhaps I'm misunderstanding your concern, but it doesn't look like js allocates for the actual object just a proxy for the java.

I think you found my concern. When you are in your app code playing with native API's on the JS-side of the bridge, you are playing with mostly thin proxy objects. These proxy objects serialize your intent across the bridge, evaluate, serialize the response, and send it back to you over the bridge.

This is exactly what React Native does too. The difference is how much of this is done. NativeScript encourages you to stay on the JS side of the bridge- that's why they surfaced those API's. React Native encourages you to cross the bridge to do heavy lifting and then bring the final answer back. This means you typically end up utilizing the bridge a lot more for similar features in NativeScript than you would for React Native. Of course, you pay for this in React Native by having to write Native modules. (I'm purposefully ignoring some of the work I've seen in the RN community to surface these API's in the same way that NativeScript does).

At the bottom of that article there are suggestions on how to mitigate some of these problems, and just about all of them relate to minimizing unnecessary trips across the bridge.

Post reply on HN