Hacker News Reader

Comment by dan_manges | Hacker News Reader

We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is much faster with React Native than what we were able to achieve building natively. Our app has over 100 screens, and only needing to implement features once to have them on both platforms is nice. The feedback loop when making code changes is much faster, especially when writing unit tests. There are some rough edges, but the benefits far outweigh the costs for us.

Our iOS app: https://itunes.apple.com/us/app/root-car-insurance/id1021256...

Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.r...

View on HN

It benefits your dev team, but does it benefit your customers?

How's the battery usage of your RN app vs a real native app? Does your app require the latest phone hardware to run with decent performance?

As one of the designers of this app, I was skeptical initially if there would be restrictions on customizing common UI components, the smoothness of animations/interactions, usability, performance, etc. You definitely have to put in a bit of extra work (isn't that always the case with making things nice though), but you can get very nice results (and battery usage) with RN for sure on both Android and iOS. Personally, I think it does benefit customers to be able to quickly roll out iterations across operating systems at a high quality. YMMV though, what works for one team, industry and customer base naturally doesn't automatically work for everyone. Do you maybe have experience or data points on RN vs. native in terms of battery usage and performance? Would love to hear any insights you can share. Thanks.

One of the reasons I brought this up was a recent article about energy efficiency of programming languages.[1] JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery.

[1] https://sites.google.com/view/energy-efficiency-languages/re...

"so it will eat twice the battery" may be nearly true on headless boxes running CPU heavy workloads. Mobile apps are about as far from that as you can possibly get. Sure it's probably a measurable impact, but I would expect it's less of an impact than things like how bright the backlighting is, whether you keep GPS usage to a minimum, how well you minimize and batch network communication, etc, etc. CPU is a small part of a phone's power budget and mobile apps spend a lot of time with the cpu largely idle.

> JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery.

While the citation you provide is interesting, it doesn't inherently prove that in real-world usage, React Native apps consume twice the power of their native counterparts.

Wow, that's a great analysis. In addition to being less efficient, there's definitely more overhead with the extra layer of JS underneath. Just of the top of my head, this might be a bigger issue with apps that constantly refresh the screen or have real-time interactions (e.g. games or Slack), and not so much apps that are essentially a series of forms (code only runs when you interact). With our app, what affects battery usage most is the location analysis that happens in the background. It's one of the areas the development team spends a lot of time testing and optimizing.

This is worth a look[1]. Make sure to see charts at bottom.

> Swift won overall in the CPU category, React-Native won the GPU category (barely), and React-Native won big time in the Memory category.

[1]: https://medium.com/the-react-native-log/comparing-the-perfor...

React Native is native. It's nothing like trying to shoehorn rich client functionality and animations into a web view.

JavaScript still much slower and more memory-hungry than Objective C.

Yes, and 99% of the code running in a React Native app is written in Objective-C, because they are native widgets and native libraries (often just the AppKit widget or a wrapper around it). That's why it's called React Native.

The JS runtime is only used to choreograph different native components. It's like a .xib or storyboard but with the ability to do logic. This code runs at user input speed so the relative performance characteristics are irrelevant.

How do you manage 100+ screens?

I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens.

Wix's "React Native Navigation" was too opinionated / inflexible.

The best nav experience I've had with RN is React Navigation: https://reactnavigation.org/

I've had an ok experience with React Navigator, but still feels very immature (I was unable to implement relatively straightforward animations on the parent view in a transition), and it also feels like interface builder/storyboards leaves it in the dust in terms of wiring together interfaces and getting a high-level overview of the information architecture of an app.

How does it compare with react-native-navigation?

Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two

[1]: https://i.imgur.com/etEa7WT.png

I recently gave a talk at Chain React in Portland (first ever React Native only conference) where I compared these two nav stacks:

https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s

The situation with navigation and React Native is a bit of a mess right now.

Basically all navigation stacks can be broken down into two categories, those that are native (i.e built on top of the OS's existing navigation stack) and those that are not (pure javascript, emulates what the native stack does).

Examples of Native navigation stacks:

-> React Native Navigation (wix)

-> Native Navigation (Airbnb)

Examples of Javascript navigation stacks:

-> React Navigation

-> React Native Router Flux

-> React Router Native

An example app I wrote with React Navigation + Redux:

https://github.com/hgale/ReactNavigationDemo

Same app but built with React Native Navigation + redux:

https://github.com/hgale/ReactNativeNavigationDemo

The main differences are that the native nav stacks have better performance, stuff like accessibility works right out of the box and they work the same way that the underlying native system works.

The main downside to using Native navigation stacks right now is that setting then up & upgrading them can be a real pain. It can also require native knowledge when things go wrong.

I would recommend staying with react navigation (Javascript based nav stack) unless you absolutely need some feature from one of these native nav stacks.

It's going to be a lot easier to upgrade and you won't run into issues doing over the air updates with your production apps.

It's also the one that Facebook promotes in their docs:

https://facebook.github.io/react-native/docs/navigation.html

Right now both React Native Navigation and React Navigation are under heavy development. No matter which one you choose, budget for some pain in the next year when upgrading.

I would think that having to learn a little about iOS/Android would be a small price to pay for decent performance and accessibility. The idea that those are only sometimes important rather than a necessity is alien to me as a software developer and as a user.

I agree, accessibility is important and in many countries required by law. However using React Native Navigation can be quite a lot of work for a shop that only has JS dev's who've never done native. Using React Native Navigation (or any native dependency) also has implications for your CI system, debugging and over the air updates.

Also you can make an app that has no accessibility problems using React Navigation, you just need to be careful about scenarios where you might have a deep stack. I.e during signup or something that requires several screens on top of one another.

Here is a summary of the bug:

https://react-native.canny.io/feature-requests/p/navigator-b...

It's painful but possible to work around these issues using React Navigation.

I agree and even go one step further by saying that I'd never publish an RN app without native navigation.

Looks very good, will have to try it out.

I found quite the opposite, it's much easier to manage many activities, I am guessing you were using your own 'routing'? Take a look at react-navigation or react-router (it supports react-native too)

I was looking for libraries that use native code but react-native-navigation was too opinionated and Air BnB's solution wasn't and isn't production ready.

I pretty much put the project down after that and started learning Swift (I already do Android).

Now I decided to go all out on iOS dev with the hope of making a career change from web.

One control per screen

It's actually quite easy

Do you share any of your code base with a web app?

We don't right now. We're a car insurance carrier that uses our mobile app to gather data as people drive. Since all of our customers have our app installed, we haven't looked to building a web app version yet. Although we could reuse some logic on the web, the overlap would be minimal. Most of the code is centered around the UI, and a web app would likely have a very different interface. It would be nice to share some business logic functions, although we tend to not put much of that in the client anyway. Most of it happens server-side, with client hitting APIs to check business rules.

Reply on news.ycombinator.com