Live data from Hacker News

Tempted to Abandon React Native for Native Android

kelvinpompey.me

51–60 of 63 posts

Re: Tempted to Abandon React Native for Native Android

#51
post #50

Earlier quoted context omitted.

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 s…

[deleted]

Re: Tempted to Abandon React Native for Native Android

#52
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…

My main gripe is that for practical purposes is all react-native or nothing.

I will be happy if use React ONLY for the UI, and use swift/.net for all the rest. But merge both is problematic (as far I know).

Exist a way to achieve this? Where I can use react only for the design of the UI and fully native elsewhere?

Re: Tempted to Abandon React Native for Native Android

#53
post #45

Earlier quoted context omitted.

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.

I'm not an expert, but I think that there is a different approach between React / React Native and SWT. SWT created layer of abstractions - when using their apis you were writing code once - and it was supposed to work the same way on all supported platforms. However React / React Native just use the same React paradigm to rendering controls, but the controls themselves are specific to the platforms. What you share is all the code that is not views, but views themselves are separate codes.

Re: Tempted to Abandon React Native for Native Android

#54
post #52
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…

My main gripe is that for practical purposes is all react-native or nothing. I will be happy if use React ONLY for the UI, and use swift/.net for all the rest. But merge both is problematic (as far I know). Exist a way to achieve this? Where I can use react only for the design of the UI and fully native elsewhere?

It's fairly straightforward but you need to write some Obj-C, I don't think you can do it entirely in Swift yet. It's pretty painless in iOS, YMMV on Android. See here for details: https://facebook.github.io/react-native/docs/native-modules-...

Re: Tempted to Abandon React Native for Native Android

#55
post #45

Earlier quoted context omitted.

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.

I'm not an expert, but I think that there is a different approach between React / React Native and SWT. SWT created layer of abstractions - when using their apis you were writing code once - and it was supposed to work the same way on all supported platforms. However React / React Native just use the same React paradigm to rendering controls, but the controls themselves are specific to the platforms. What you share i…

I've been working pretty extensively with RN these days.

Almost always, the code is the same (doesn't HAVE to be though but almost always is), and even the views are the same (barring some exceptions where Android and iOS have completely different design language requiring you to customize things at the code level using platform conditionals in the same source file).

Re: Tempted to Abandon React Native for Native Android

#56

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've played around with NativeScript a fair bit. It's very, very clever, but I'm not really sure what it gives you beyond just doing native development. Sure, you get to use JavaScript, but you have to write separately for each platform if you break out of their custom UI components, and debugging, testing, etc. etc. is more complicated and annoying that just writing in (my case) Swift and using native tools.

Re: Tempted to Abandon React Native for Native Android

#58
post #17
post #11

To summarize this article: The author really enjoyed using React Native up until he hit some performance issues related to loading large images on certain versions of Android. He doesn't go into what specifically the performance issues were, any techniques he used to profile his app, what third party libraries he tired or anything. Performance issues happen all the time with native apps that don't use React Native. O…

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…

Hey, RN Android dev here: re: object finalizers:

- For Fresco, I think Balazs provided a pretty good response here on how Fresco uses the finalizers (https://github.com/facebook/react-native/issues/8711#issueco...). If you still think there's an issue here, I'll direct Balazs to this post. - For RN, I remember the issue you cited stated that using Object.finalize is 430x slower than having no finalizer, which sounds really bad until you realize we're talking about 430x slower than 5.6ns. Even though we may create thousands of these objects during a typical startup, this cost adds up to a couple of ms across startup -- since we had other ideas for more impactful perf improvement, we didn't take this on, especially since the proposed alternative at the time was to but the onus on developers to remember to manually free these objects. That being said, we've switch to using PhantomReferences internally at FB for this (which is strikes us as a better solution than either of the above), and hopefully will sync that with open source soon.

Re: bridge serialization, I'm sorry that issue fell through the cracks, I'll make sure that we follow up on it internally. I think there's a meta-issue around communication here on issues and PRs, and while there are a ton to follow up on every day, the RN team could be doing better following up on the important ones that need addressing from the team (I think the bridge serialization issue qualifies), and setting proper expectations on all others. I'll follow up on that internally as well.

I apologize on behalf of the team that it's been frustrating -- I promise we do appreciate all the help we get from the community and try to balance working on our internal goals and with the community as best as possible.

Re: Tempted to Abandon React Native for Native Android

#59
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…

facebook actually recommends using yarn instead of npm. it has faster install times.

Yarn is categorically better than npm at dependency management, in addition to its speed. Yarn uses a lock file to pin exact versions no matter what semver range you choose. When you add another dependency, it does not have the side effect of updating other modules. When you run yarn install it downloads the exact package versions described in the lock file rather than the latest version it can get from npm in that range. This ensures you get back to the last working state. Updating modules to the latest in their range is a separate command.

Re: Tempted to Abandon React Native for Native Android

#60

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 Bu…

Yes, it literally works like that. See the docs: http://docs.nativescript.org/cookbook/application

The variable is app.ios / app.android

Post reply on HN