4 ms·

I’ve never seen anyone do a battery impact analysis of React Native. I wonder why? Person sally, I don’t want to use products where the developer prioritizes t

I’ve never seen anyone do a battery impact analysis of React Native. I wonder why? Person sally, I don’t want to use products where the developer prioritizes their problems over my experiencs but YMMV. Some will argue that an Electron dumpster fire is superior to nothing. I consider that debatable.

rimliu 8y ago
I am still waiting for tide to turn and for times when users mattered to come back. Not sure if it ever will.
- mkohlmyr 8y ago
  I don't buy this sentiment one bit. In my opinion this nostalgia is almost entirely unjustified unless your primary metric of "when users mattered" is "software used less RAM and CPU". Which may not even be factually correct from a percentage of available resources perspective. Modern day software applications are far more accessible and usable on average than those of the 90s and 00s. And that's the metric that actually matters. More people are able to do more things with software.
ricardobeat 8y ago
RN is nothing like an Electron app though. Rendering is fully native, no browser engine involved. It does add not-insignificant overhead due to JSC, Yoga and native bridge, but it will depend a lot on the nature of the app.
bengotow 8y ago
Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.
- maga_2020 8y ago
  I agree with you, that for the same 'business logic', having it JavaScript vs native, unless you do lots of sorting/copying of data -- will not have battery impact difference. However, React itself (not the javascript engine) brings in additional dimensions, that are somewhat unique to react. For example, React's (and therefore ReactNative) TextInput control, essentially (in my understanding) encourages you to update a state variable, every single time type a letter into that control (because the values displayed in the control are coming from the state, so the only way to display the character you typed, is via updating the state). So that round trip of the character update, to updating the object with state variable, calling .setState, forcing the re-rendering, will consume more battery power. In my view (I know textinput in particular has the 'uncontrolled model'). My point, that the constant 'create new object', update the state with it, and Re-render -- could be slower (and less battery efficient), than doing may be something similar (or more efficient) in Native Code.
jczhang 8y ago
Repeating what someone else has said, React Native is not Electron.

rimliu 8y ago

I am still waiting for tide to turn and for times when users mattered to come back. Not sure if it ever will.

mkohlmyr 8y ago
I don't buy this sentiment one bit. In my opinion this nostalgia is almost entirely unjustified unless your primary metric of "when users mattered" is "software used less RAM and CPU". Which may not even be factually correct from a percentage of available resources perspective. Modern day software applications are far more accessible and usable on average than those of the 90s and 00s. And that's the metric that actually matters. More people are able to do more things with software.

ricardobeat 8y ago

RN is nothing like an Electron app though. Rendering is fully native, no browser engine involved. It does add not-insignificant overhead due to JSC, Yoga and native bridge, but it will depend a lot on the nature of the app.

bengotow 8y ago

Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.

maga_2020 8y ago
I agree with you, that for the same 'business logic', having it JavaScript vs native, unless you do lots of sorting/copying of data -- will not have battery impact difference. However, React itself (not the javascript engine) brings in additional dimensions, that are somewhat unique to react. For example, React's (and therefore ReactNative) TextInput control, essentially (in my understanding) encourages you to update a state variable, every single time type a letter into that control (because the values displayed in the control are coming from the state, so the only way to display the character you typed, is via updating the state). So that round trip of the character update, to updating the object with state variable, calling .setState, forcing the re-rendering, will consume more battery power. In my view (I know textinput in particular has the 'uncontrolled model'). My point, that the constant 'create new object', update the state with it, and Re-render -- could be slower (and less battery efficient), than doing may be something similar (or more efficient) in Native Code.

jczhang 8y ago

Repeating what someone else has said, React Native is not Electron.