3 ms·

I would love to see their test using a regular Android device, not a high end iPhone. Android has like 90%? worldwide market share and most phones are way unde

by pier25 4y ago

I would love to see their test using a regular Android device, not a high end iPhone. Android has like 90%? worldwide market share and most phones are way underpowered vs even old iPhones. Picking a solution that only works well for SV users is a terrible decision.

brundolf 4y ago
RN uses native controls (not a webview) and JS is plenty fast for most UI logic (it's almost never the bottleneck on slow web apps), so I would not expect performance to be a problem here
- pier25 4y ago
  RN is quite inefficient and perf issues will not be obvious if using high end devices. Which is why Meta is working on Hermes: https://engineering.fb.com/2019/07/12/android/hermes/ https://engineering.fb.com/2019/07/12/android/hermes/
  - deleted 4y ago
    [deleted]
  - actualwitch 4y ago
    Hermes is already enabled by default in rn.
    - danielrhodes 4y ago
      If you can get away with it, it's not a bad option. But it's still early days. If you run into compatibility problems or bugs with libraries being used, you could be in trouble.
  - siquick 4y ago
    That’s from almost 3 years ago. RN had changed a lot since then (and Hermes is included by default now) https://reactnative.dev/architecture/bundled-hermes https://reactnative.dev/architecture/bundled-hermes
- danielrhodes 4y ago
  React Native is much slower on Android than on iOS, sometimes by orders of magnitude. You can get things usable on a lower-end Apple device, but on a lower-end Android an optimized RN app is still unusable. Part of this is due to the JS interpreter available on Android (which FB has tried to replace). But I think it's also due to architectural issues in Android itself and the natural overhead that RN has being too much in a constrained environment.
  - fleddr 4y ago
    The real reason is the shitty CPU on typical low-end to mid-end Androids. They suck at running JS. And I mean REALLY suck, as in 5-10 times slower than an iPhone. I recently came across a ridiculous example of a high-end Chinese phone (700$) where one our web app's interactions that normally is near-instant, took 6s instead. Turns out that besides the generic issue of poor JS performance on Android (due to CPU), this particular manufacturer decided to deliver on their ridiculous battery life claims by...running all JS on a low energy CPU core.
    - danielrhodes 4y ago
      Right. As much as people want to complain about Apple forcing WebKit/View on everyone, what it has enabled them to do is build specific hardware level optimizations in for JS and page rendering, which means you can get really good desktop-level performance even with an otherwise limited CPU/battery. Given Chrome's horrendous issues on MacOS, they are going to drain the battery as fast as possible and then blame it on Apple. Chrome users will then blame Apple for bad battery life.
    - pier25 4y ago
      > The real reason is the shitty CPU on typical low-end to mid-end Android Well yeah would you expect it to be otherwise? These devices cost a fraction of an iPhone. People in the US don't realize iPhones are luxury products for the majority of people in the world.
      - fleddr 4y ago
- lawgimenez 4y ago
  I like your confidence but obviously you haven’t released an app in an Asian market. Performance is an issue here since most are using outdated Android phones from average of 5 years ago.
  - pier25 4y ago
    Exactly. Same with the LATAM market. Most are using old Android devices or sub $200 devices.
ksec 4y ago
>Android has like 90%? worldwide market share Android including Chinese Android at best are ~75% market share. But your point still stands though.
- pier25 4y ago
  You're right. Just checked it and in some markets like India it's about 90% but globally it's more like 70%. But yeah my point is that US devs (specially SV devs) tend to be myopic about this as they are using iPhones like most people in their bubble. If you're making an app for the US market then this is probably less of an issue, but for worldwide audience this is a huge issue. Not only with RN but with web apps too.

by pier25 4y ago

brundolf 4y ago

RN uses native controls (not a webview) and JS is plenty fast for most UI logic (it's almost never the bottleneck on slow web apps), so I would not expect performance to be a problem here

pier25 4y ago
RN is quite inefficient and perf issues will not be obvious if using high end devices. Which is why Meta is working on Hermes: https://engineering.fb.com/2019/07/12/android/hermes/ https://engineering.fb.com/2019/07/12/android/hermes/
- deleted 4y ago
  [deleted]
- actualwitch 4y ago
  Hermes is already enabled by default in rn.
  - danielrhodes 4y ago
    If you can get away with it, it's not a bad option. But it's still early days. If you run into compatibility problems or bugs with libraries being used, you could be in trouble.
- siquick 4y ago
  That’s from almost 3 years ago. RN had changed a lot since then (and Hermes is included by default now) https://reactnative.dev/architecture/bundled-hermes https://reactnative.dev/architecture/bundled-hermes
danielrhodes 4y ago
React Native is much slower on Android than on iOS, sometimes by orders of magnitude. You can get things usable on a lower-end Apple device, but on a lower-end Android an optimized RN app is still unusable. Part of this is due to the JS interpreter available on Android (which FB has tried to replace). But I think it's also due to architectural issues in Android itself and the natural overhead that RN has being too much in a constrained environment.
- fleddr 4y ago
  The real reason is the shitty CPU on typical low-end to mid-end Androids. They suck at running JS. And I mean REALLY suck, as in 5-10 times slower than an iPhone. I recently came across a ridiculous example of a high-end Chinese phone (700$) where one our web app's interactions that normally is near-instant, took 6s instead. Turns out that besides the generic issue of poor JS performance on Android (due to CPU), this particular manufacturer decided to deliver on their ridiculous battery life claims by...running all JS on a low energy CPU core.
  - danielrhodes 4y ago
    Right. As much as people want to complain about Apple forcing WebKit/View on everyone, what it has enabled them to do is build specific hardware level optimizations in for JS and page rendering, which means you can get really good desktop-level performance even with an otherwise limited CPU/battery. Given Chrome's horrendous issues on MacOS, they are going to drain the battery as fast as possible and then blame it on Apple. Chrome users will then blame Apple for bad battery life.
  - pier25 4y ago
    > The real reason is the shitty CPU on typical low-end to mid-end Android Well yeah would you expect it to be otherwise? These devices cost a fraction of an iPhone. People in the US don't realize iPhones are luxury products for the majority of people in the world.
    - fleddr 4y ago
lawgimenez 4y ago
I like your confidence but obviously you haven’t released an app in an Asian market. Performance is an issue here since most are using outdated Android phones from average of 5 years ago.
- pier25 4y ago
  Exactly. Same with the LATAM market. Most are using old Android devices or sub $200 devices.

ksec 4y ago

>Android has like 90%? worldwide market share Android including Chinese Android at best are ~75% market share. But your point still stands though.

pier25 4y ago
You're right. Just checked it and in some markets like India it's about 90% but globally it's more like 70%. But yeah my point is that US devs (specially SV devs) tend to be myopic about this as they are using iPhones like most people in their bubble. If you're making an app for the US market then this is probably less of an issue, but for worldwide audience this is a huge issue. Not only with RN but with web apps too.