Hacker News Reader

Comment by snarfy | Hacker News Reader

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?

View on HN

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

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.

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

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

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.

Reply on news.ycombinator.com