16 ms·

Going Mobile With React Native

43 points by Fermin 9y ago

LeoNatan25 9y ago
“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.
  - 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
wimagguc 9y ago
It's not really tips, is it, it's just a high-level React-Native-exists article. While I'm on though, what I'd really want to see in the next great-tips article are: (1) How to make a project more future-proof? (Try it yourself: download any React Native demo app from the past 1-2 years, and see how many of those compiles without complaining about version, platform, what-not.) (2) An actual cost analysis of a React Native project. My experience is that since most developers are still just learning RN, the good ones are too expensive or too busy, and you'll actually end up paying more for the same app.
- haterswillhate 9y ago
  Its like these comments just stole my words :) Companies will save time by using frameworks to get product ready. They should really think how future proof the product is more carefully. Its amazing how "loosely" projects are build in big companies because everything need to be ready in 2 or 3 week. Development these days is dangerously going more and more copy paste process. Averange company do not support benchmarks or any other optimisations if it take more than 1 or 2 days to complete.
- mkalygin 9y ago
  I can confirm the (1) problem. Recently I've tried to compile the app which was built in March 2017 and this was unpleasant and painful process: lots of build errors, version inconsistencies, etc. Regarding (2) I think that good developers are always expensive, no matter which technology they use.
k__ 9y ago
React-Native is pretty good, mostly feels like doing regular React (web) development. And if you get perf problems, just write things in the native languages with a bridge. Not THE way to do mobile apps, but if you already know React, it's the way to go.
prodtorok 9y ago
As a professional JS and iOS developer, I have to say that React Native is not the way to ever go unless you need to quickly prototype proof-of-concepts. I'm in love with React, but not RN. Apps just don't feel right (like something is off but you can't tell what), annoying bugs, hacky open source modules, and the fear that it will never live up to it's hype or be able to keep up with native apis. If you need a quick poc, then use what you're most comfortable with. If your app is simple enough to make in RN, then do it in native. If your app is complicated then you won't be able to do it (successfully) in RN anyway.
pawelwentpawel 9y ago
I work with both native iOS and React Native on daily basis. Both had their own (dis)advantages and it's hard to have a definite answer on which is better. It all depends on the nature of the app you want to build, your budget and trade-offs you are willing to take. RN is moving fast and has improved a lot in the recent months but still has some pain points: - If you want to build a chat app, forget about well working sticky text input. (https://github.com/facebook/react-native/issues/371 https://github.com/facebook/react-native/issues/371) - All the dev time you have saved with hot reloading will be lost if you hit the infamous 4968 (https://github.com/facebook/react-native/issues/4968 https://github.com/facebook/react-native/issues/4968) - Multithreading, but that has been covered in other comments. If you're obsessed about buttery smooth UI you'll have some unpleasant time. Also : - I find RN's ecosystem feeble and don't trust packages. Triple check everything you run npm install on. - Using solely RN/JS is not an excuse to completely avoid learning native development. It bites in the future. + ScrollViews are great. + Build times are shorter, you get quicker feedback especially for UI small modifications. + I really enjoy working with RN's Animated API.
- udfalkso 9y ago
  This is a good list of pros and cons. I'd just add this: + App also runs on Android (and even web, and tvos) I'm always surprised when people don't list this massive benefit when discussing RN. It's really the core value proposition. The fact that it's even in the conversation when developing for only one platform seems like quite an endorsement of the developer experience with RN.
  - pawelwentpawel 9y ago
    Definitely. That is also my main reason for mentioning the budget - building one app for multiple platforms is (usually...) cheaper.
- LeoNatan25 9y ago
  Scrollviews are relatively easy, but table (list) views and collection views are terrible due to the way RN is implemented internally. FlatList, while a small optimization over the normal ListView, is still just not good enough.
mcbobbington 9y ago
The newer react-navigation is actually a decent router. Before that the routing options were pretty bad

43 points by Fermin 9y ago

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

wimagguc 9y ago

It's not really tips, is it, it's just a high-level React-Native-exists article. While I'm on though, what I'd really want to see in the next great-tips article are: (1) How to make a project more future-proof? (Try it yourself: download any React Native demo app from the past 1-2 years, and see how many of those compiles without complaining about version, platform, what-not.) (2) An actual cost analysis of a React Native project. My experience is that since most developers are still just learning RN, the good ones are too expensive or too busy, and you'll actually end up paying more for the same app.

haterswillhate 9y ago
Its like these comments just stole my words :) Companies will save time by using frameworks to get product ready. They should really think how future proof the product is more carefully. Its amazing how "loosely" projects are build in big companies because everything need to be ready in 2 or 3 week. Development these days is dangerously going more and more copy paste process. Averange company do not support benchmarks or any other optimisations if it take more than 1 or 2 days to complete.
mkalygin 9y ago
I can confirm the (1) problem. Recently I've tried to compile the app which was built in March 2017 and this was unpleasant and painful process: lots of build errors, version inconsistencies, etc. Regarding (2) I think that good developers are always expensive, no matter which technology they use.

k__ 9y ago

React-Native is pretty good, mostly feels like doing regular React (web) development. And if you get perf problems, just write things in the native languages with a bridge. Not THE way to do mobile apps, but if you already know React, it's the way to go.

prodtorok 9y ago

As a professional JS and iOS developer, I have to say that React Native is not the way to ever go unless you need to quickly prototype proof-of-concepts. I'm in love with React, but not RN. Apps just don't feel right (like something is off but you can't tell what), annoying bugs, hacky open source modules, and the fear that it will never live up to it's hype or be able to keep up with native apis. If you need a quick poc, then use what you're most comfortable with. If your app is simple enough to make in RN, then do it in native. If your app is complicated then you won't be able to do it (successfully) in RN anyway.

pawelwentpawel 9y ago

I work with both native iOS and React Native on daily basis. Both had their own (dis)advantages and it's hard to have a definite answer on which is better. It all depends on the nature of the app you want to build, your budget and trade-offs you are willing to take. RN is moving fast and has improved a lot in the recent months but still has some pain points: - If you want to build a chat app, forget about well working sticky text input. (https://github.com/facebook/react-native/issues/371 https://github.com/facebook/react-native/issues/371) - All the dev time you have saved with hot reloading will be lost if you hit the infamous 4968 (https://github.com/facebook/react-native/issues/4968 https://github.com/facebook/react-native/issues/4968) - Multithreading, but that has been covered in other comments. If you're obsessed about buttery smooth UI you'll have some unpleasant time. Also : - I find RN's ecosystem feeble and don't trust packages. Triple check everything you run npm install on. - Using solely RN/JS is not an excuse to completely avoid learning native development. It bites in the future. + ScrollViews are great. + Build times are shorter, you get quicker feedback especially for UI small modifications. + I really enjoy working with RN's Animated API.

udfalkso 9y ago
This is a good list of pros and cons. I'd just add this: + App also runs on Android (and even web, and tvos) I'm always surprised when people don't list this massive benefit when discussing RN. It's really the core value proposition. The fact that it's even in the conversation when developing for only one platform seems like quite an endorsement of the developer experience with RN.
- pawelwentpawel 9y ago
  Definitely. That is also my main reason for mentioning the budget - building one app for multiple platforms is (usually...) cheaper.
LeoNatan25 9y ago
Scrollviews are relatively easy, but table (list) views and collection views are terrible due to the way RN is implemented internally. FlatList, while a small optimization over the normal ListView, is still just not good enough.

mcbobbington 9y ago

The newer react-navigation is actually a decent router. Before that the routing options were pretty bad