8 ms·

“When you build your application in React Native, you are still running native code in an native app using a native framework. The Javascript framework is just

“When you build your application in React Native, you are still running native code in an native app using a native framework. The Javascript framework is just handling the business logic.” No, this is incorrect. Using merely UIView objects does not mean it is native. It’s not just an abstraction over native. Unlike something like NativeScript, the “great” minds at Facebook have decided to not only offer a JS wrapper around the native, but actually reinvent the wheel on everything. Tables? Let’s have a horrible implementation in JS. Gestures? In JS. Navigation? In JS. Animations? Core Animation you say? Nope. Even simple stuff like buttons are not native UIButton objects. There is nothing “native” in React Native. Also, the single threaded model of JS just does not scale. The larger the app gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but the lag comes from a constantly busy single JS thread. And that’s before mentioning things like accessibility, large type support, basic iOS concepts such as margins and layout guides, etc. that are sorely missing from RN. You want a ‘great’ tip? Don’t cheap out; hire native developers. Otherwise your users will suffer a lackluster and inferior product that looks nothing like the platform it’s running on.

whizzkid 9y ago
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
  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
haterswillhate 9y ago
Very good and accurate comment. This "native" in react is just an illusion that so many companies are believing. Native is best way to produce code. Sometimes a bit rocky and longer development times but in long run more beneficial..
calvin_c 9y ago
Could not agree more. There are certainly benefits to using React Native, especially when bootstrapping an app and you've already got a React shop, but once your app and user base gets larger it creates a serious barrier to actually taking advantage of the native platform and it's capabilities.
cel1ne 9y ago
Regarding the margin and layout guides: You can use Tachyons.css on react-native to easily achiever proper layouts: https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons
- LeoNatan25 9y ago
  The problem is that since the native system of the OS are not used, you always play catch up with the OS in order to look fully native. It just doesn’t scale.
  - calvin_c 9y ago
    Exactly. It’s an abstraction, you will always be a few libraries and components away from implementing what you actually want, but that’s a lot to build on just to use a system provided tool. For instance, I’m working on upgrading my company’s app to use iOS 11’s new password auto fill APIs. All it needs is for you to set the UITextField’s contentType properly to one of a dozen enumerated values, in this case Username and Password. React Native doesn’t expose that propertie on the TextField component however, so I have to either build my own extension on top of the TextField component or form the React Native project and submit a PR to get this feature working, a feature that’s explicitly supposed to be painless to implement. There are so many cases like this around React Native, the community mindset is usually just to find another dependency to integrate.
    - LeoNatan25 9y ago
      “the community mindset is usually just to find another dependency to integrate.” I fear it’s JS development mindset in general. I mean, you start a new project in RN, you get 1200 NPM dependencies. You start work, and you get thousands of dependencies. All that piles up to a huge amount of code that has to be parsed on start up (no ahead of time compilation or JIT).
      - cel1ne 9y ago
        That is one of my pains with react-native and the JS-community. Their tooling sucks, because they use javascript for everything. Having a NullPointerException/"undefined" in my code means I have to go hunt the bug for a couple of minutes. Having it in my buildtool means I my productivity drops to zero for an hour. RN also keeps using deprecated and old version of android-buildtools. Fun fact: "NullPointerException" gives 2.47 million results on google. "cannot read property of undefined" gives 3.71 million results. (Background: I'm a Java, Kotlin and JavaScript developer, shipped an app using react-native for the Views only, but Kotlin for the business-logic. I also picked some fights with the RN-maintainers on github issues.)
continuations 9y ago
If all UI components in React Native are implemented in JS then what is "native" about it? Is NativeScript more native than React Native? Also is NativeScript multithreaded?
- LeoNatan25 9y ago
  NativeScript is still single threaded. It’s the nature of the beast. On the other hand, NativeScript's UI mapping is directly on top of the platform widgets, as far as I remember.
  - calvin_c 9y ago
    Correct. Every React Native component actually renders into a native view, so on iOS if you use a View (RN) it maps to a UIView when React Native actually builds the UI.
    - LeoNatan25 9y ago
      Mapping to UIView is about the only thing that is “native” about React Native. My comment was about Native Script, which uses actual native widgets and concepts, such as controllers, animations systems, navigation, etc.
idibidiart 9y ago
Most of your reaction is anger and hate. That cannot be the truth. The truth is always balanced. If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true. The whole point of React Native is to develop apps for both iOS and Android (you seem to be an iOS focused developer so you wouldn't care but many of us are targetting both) and doing that easily (for those who build RN and those who use it) means we have to create a standard set of behaviors that work across both platforms and work far better than running a web app in a webview. React Native achieves that goal. But it also has an enormously capable ecosystem with companies like Airbnb and Wix making substantial contributions to things like Native cross platform Navigation libraries. When it comes to threading, the native views run in the main UI thread (just like native views would in any native environment) while the JS business logic runs in its own thread. To minimize serialization costs between JS and Native a lot has been done so JS objects like styles are passed by numeric reference. You can always use something like react-native-fetch-blob to natively fetch an image or some other heavy asset and go around the JS-Native bridge. But you can also use Inage component to fetch and remder images without serializing over the bridge. The user community has many other examples and great libraries to complement React Native. All you have to do is be curious rather than judgemental and harshly criticizing things that you obviously lack in-depth knowledge about. When it comes to layout, Flexbox and support for percentage based siIng give us the primitives we need to replicate the familiar responsive grid systems we use on the web. See this for example: https://github.com/idibidiart/react-native-responsive-grid https://github.com/idibidiart/react-native-responsive-grid And as far back as August 2015, I was able to create a custom keyboard in Obj-C and expose it as a React Native component: https://m.youtube.com/watch?v=YV3p09KoYKw https://m.youtube.com/watch?v=YV3p09KoYKw There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving. So Facebook has shared their work with us and we shared our work with the community. What do you have to share besides criticism of other people's work? Do you have any work of your own that helps others build things? Put it out there and open it to criticism from random folks on the internets. Let's see your true genius!
- LeoNatan25 9y ago

whizzkid 9y ago

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

haterswillhate 9y ago

Very good and accurate comment. This "native" in react is just an illusion that so many companies are believing. Native is best way to produce code. Sometimes a bit rocky and longer development times but in long run more beneficial..

calvin_c 9y ago

Could not agree more. There are certainly benefits to using React Native, especially when bootstrapping an app and you've already got a React shop, but once your app and user base gets larger it creates a serious barrier to actually taking advantage of the native platform and it's capabilities.

cel1ne 9y ago

Regarding the margin and layout guides: You can use Tachyons.css on react-native to easily achiever proper layouts: https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons

LeoNatan25 9y ago
The problem is that since the native system of the OS are not used, you always play catch up with the OS in order to look fully native. It just doesn’t scale.
- calvin_c 9y ago
  Exactly. It’s an abstraction, you will always be a few libraries and components away from implementing what you actually want, but that’s a lot to build on just to use a system provided tool. For instance, I’m working on upgrading my company’s app to use iOS 11’s new password auto fill APIs. All it needs is for you to set the UITextField’s contentType properly to one of a dozen enumerated values, in this case Username and Password. React Native doesn’t expose that propertie on the TextField component however, so I have to either build my own extension on top of the TextField component or form the React Native project and submit a PR to get this feature working, a feature that’s explicitly supposed to be painless to implement. There are so many cases like this around React Native, the community mindset is usually just to find another dependency to integrate.
  - LeoNatan25 9y ago
    “the community mindset is usually just to find another dependency to integrate.” I fear it’s JS development mindset in general. I mean, you start a new project in RN, you get 1200 NPM dependencies. You start work, and you get thousands of dependencies. All that piles up to a huge amount of code that has to be parsed on start up (no ahead of time compilation or JIT).
    - cel1ne 9y ago
      That is one of my pains with react-native and the JS-community. Their tooling sucks, because they use javascript for everything. Having a NullPointerException/"undefined" in my code means I have to go hunt the bug for a couple of minutes. Having it in my buildtool means I my productivity drops to zero for an hour. RN also keeps using deprecated and old version of android-buildtools. Fun fact: "NullPointerException" gives 2.47 million results on google. "cannot read property of undefined" gives 3.71 million results. (Background: I'm a Java, Kotlin and JavaScript developer, shipped an app using react-native for the Views only, but Kotlin for the business-logic. I also picked some fights with the RN-maintainers on github issues.)

continuations 9y ago

If all UI components in React Native are implemented in JS then what is "native" about it? Is NativeScript more native than React Native? Also is NativeScript multithreaded?

LeoNatan25 9y ago
NativeScript is still single threaded. It’s the nature of the beast. On the other hand, NativeScript's UI mapping is directly on top of the platform widgets, as far as I remember.
- calvin_c 9y ago
  Correct. Every React Native component actually renders into a native view, so on iOS if you use a View (RN) it maps to a UIView when React Native actually builds the UI.
  - LeoNatan25 9y ago
    Mapping to UIView is about the only thing that is “native” about React Native. My comment was about Native Script, which uses actual native widgets and concepts, such as controllers, animations systems, navigation, etc.

idibidiart 9y ago

Most of your reaction is anger and hate. That cannot be the truth. The truth is always balanced. If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true. The whole point of React Native is to develop apps for both iOS and Android (you seem to be an iOS focused developer so you wouldn't care but many of us are targetting both) and doing that easily (for those who build RN and those who use it) means we have to create a standard set of behaviors that work across both platforms and work far better than running a web app in a webview. React Native achieves that goal. But it also has an enormously capable ecosystem with companies like Airbnb and Wix making substantial contributions to things like Native cross platform Navigation libraries. When it comes to threading, the native views run in the main UI thread (just like native views would in any native environment) while the JS business logic runs in its own thread. To minimize serialization costs between JS and Native a lot has been done so JS objects like styles are passed by numeric reference. You can always use something like react-native-fetch-blob to natively fetch an image or some other heavy asset and go around the JS-Native bridge. But you can also use Inage component to fetch and remder images without serializing over the bridge. The user community has many other examples and great libraries to complement React Native. All you have to do is be curious rather than judgemental and harshly criticizing things that you obviously lack in-depth knowledge about. When it comes to layout, Flexbox and support for percentage based siIng give us the primitives we need to replicate the familiar responsive grid systems we use on the web. See this for example: https://github.com/idibidiart/react-native-responsive-grid https://github.com/idibidiart/react-native-responsive-grid And as far back as August 2015, I was able to create a custom keyboard in Obj-C and expose it as a React Native component: https://m.youtube.com/watch?v=YV3p09KoYKw https://m.youtube.com/watch?v=YV3p09KoYKw There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving. So Facebook has shared their work with us and we shared our work with the community. What do you have to share besides criticism of other people's work? Do you have any work of your own that helps others build things? Put it out there and open it to criticism from random folks on the internets. Let's see your true genius!

LeoNatan25 9y ago