5 ms·

https://facebook.github.io/react-native/showcase.html https://facebook.github.io/react-native/showcase.html I use some of the apps that are listed above, and I

https://facebook.github.io/react-native/showcase.html https://facebook.github.io/react-native/showcase.html I use some of the apps that are listed above, and I don't really have a problem with the performance. Can you explain little bit more on how not using the native components can be big problem when your app gets bigger? I am asking because i really consider using React Native. Or maybe give an example under which circumstances will those app fail to perform? I used Cordova and the "lag" makes it clear from the first 5 seconds that it is not a native app. But i haven't experienced it from the apps that they listed on their page.

martinald 9y ago
The single threaded nature is a big problem. I have led teams building large RN apps and it is then #1 problem we experience at scale. The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.
- Klathmon 9y ago
  Well you can pass TypedArrays as well (using a zero-copy "transfer" method), but that's of fairly limited use.
- JustSomeNobody 9y ago
  What does "at scale" mean in this context (mobile application)?
  - LeoNatan25 9y ago
    It means an application that is beyond displaying a short list in a two — three screens. Once you start having a real business logic, you hit the relatively low ceiling. And the usual advice of “if you need more, just write a native component” — a. does not scale in performance either and b. what’s the point, just write in native in the first place and save yourself the headache of having to learn or hire native developers at moment of crisis.
    - atoko 9y ago
      Delegate the business logic to a server, I'm not sure what kind of "real business logic" needs to live in a mobile app
      - LeoNatan25 9y ago
        Then you don’t understand mobile development. There is absolutely no need to run business logic that can run on mobile on a server. Mobile devices today are more powerful than the majority of laptops out there.
        atoko 9y ago
        Such as? Still no examples, I see. Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
        LeoNatan25 9y ago
        For example, a mail app, a chat app. Would not scale at all with RN (or mobile web in web view). Imagine having to preload hundreds or thousand messages or other existing content while the user is viewing or typing. None of that is applicable to "server side business logic". Not if you want a quality app.
        doublerebel 9y ago
        This is false, mail and chat apps work fine with multiple hybrid app frameworks. I've created plenty of hybrid apps that have 100s of items in lists, this is what ListViews are designed for. There's no limitation inherent to hybrid apps that prevents holding 1000s of objects in memory. This also works fine on mobile web if it's designed right. If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale. I'm not sure you understand how architecture of a mail or chat app would work.
LeoNatan25 9y ago
Not using native widgets/concepts and single threaded are two distinct problems. Single JS threads restricts your business logic a lot. If you start doing any serious work in JS, your app will suffer greatly. Regarding native components, the result is that views just don't look native, animations are not native (even down to different timing functions), view behaviors are different (the RN button fade out on tap is different than UIButton, etc). On top of that, since the JS thread is responsible for UI rendering and business logic, if your JS thread is busy, UI is "stuck", being unable to rerender until the JS thread is freed. All these issues pile up to create a bad result at the end. Add to that the human element (not always being mindful of performance implications), and it is worse. But, definitely, the ceiling is very low at how much you can achieve. I say all these things from experience; I work next to a team of dedicated RN developers at my company. In many cases, the need to drop to native is apparent and necessary, which makes the point of RN moot. Certainly, RN is better than Cordova; no doubt about that. But it's just not as good as many people want to fool themselves at believing.
- whizzkid 9y ago
  I see, thanks for getting into details. I guess, if you are one-man team RN makes good sense since you don't have time to write native for 2 platforms from the beginning. If your app takes off, then switch to native for scaling. Is it possible to partly switch from RN to native? something like convert components one by one to native components, while still running RN for some parts?
  - FRex 9y ago
    Why not use Xamarin's stuff to do it all in C# instead then?
    - LeoNatan25 9y ago
      Xamarin is a good choice indeed. Their constant work to create native mapping is very impressive.
    - doublerebel 9y ago

martinald 9y ago

The single threaded nature is a big problem. I have led teams building large RN apps and it is then #1 problem we experience at scale. The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.

Klathmon 9y ago
Well you can pass TypedArrays as well (using a zero-copy "transfer" method), but that's of fairly limited use.
JustSomeNobody 9y ago
What does "at scale" mean in this context (mobile application)?
- LeoNatan25 9y ago
  It means an application that is beyond displaying a short list in a two — three screens. Once you start having a real business logic, you hit the relatively low ceiling. And the usual advice of “if you need more, just write a native component” — a. does not scale in performance either and b. what’s the point, just write in native in the first place and save yourself the headache of having to learn or hire native developers at moment of crisis.
  - atoko 9y ago
    Delegate the business logic to a server, I'm not sure what kind of "real business logic" needs to live in a mobile app
    - LeoNatan25 9y ago
      Then you don’t understand mobile development. There is absolutely no need to run business logic that can run on mobile on a server. Mobile devices today are more powerful than the majority of laptops out there.
      - atoko 9y ago
        Such as? Still no examples, I see. Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
        LeoNatan25 9y ago
        For example, a mail app, a chat app. Would not scale at all with RN (or mobile web in web view). Imagine having to preload hundreds or thousand messages or other existing content while the user is viewing or typing. None of that is applicable to "server side business logic". Not if you want a quality app.
        doublerebel 9y ago
        This is false, mail and chat apps work fine with multiple hybrid app frameworks. I've created plenty of hybrid apps that have 100s of items in lists, this is what ListViews are designed for. There's no limitation inherent to hybrid apps that prevents holding 1000s of objects in memory. This also works fine on mobile web if it's designed right. If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale. I'm not sure you understand how architecture of a mail or chat app would work.

LeoNatan25 9y ago

Not using native widgets/concepts and single threaded are two distinct problems. Single JS threads restricts your business logic a lot. If you start doing any serious work in JS, your app will suffer greatly. Regarding native components, the result is that views just don't look native, animations are not native (even down to different timing functions), view behaviors are different (the RN button fade out on tap is different than UIButton, etc). On top of that, since the JS thread is responsible for UI rendering and business logic, if your JS thread is busy, UI is "stuck", being unable to rerender until the JS thread is freed. All these issues pile up to create a bad result at the end. Add to that the human element (not always being mindful of performance implications), and it is worse. But, definitely, the ceiling is very low at how much you can achieve. I say all these things from experience; I work next to a team of dedicated RN developers at my company. In many cases, the need to drop to native is apparent and necessary, which makes the point of RN moot. Certainly, RN is better than Cordova; no doubt about that. But it's just not as good as many people want to fool themselves at believing.

whizzkid 9y ago
I see, thanks for getting into details. I guess, if you are one-man team RN makes good sense since you don't have time to write native for 2 platforms from the beginning. If your app takes off, then switch to native for scaling. Is it possible to partly switch from RN to native? something like convert components one by one to native components, while still running RN for some parts?
- FRex 9y ago
  Why not use Xamarin's stuff to do it all in C# instead then?
  - LeoNatan25 9y ago
    Xamarin is a good choice indeed. Their constant work to create native mapping is very impressive.
  - doublerebel 9y ago