RN has been such a big boost of productivity for us, it changed everything. We were able to onboard junior developers that are excited to work with it as well as keeping our at the time existing native developers enthusiast about it (they embraced it since), and the time to market for us have dramatically improved for new features on both iOS and Android.
Of course some stuff sometimes doesn't work well, react-native link versus Pods, native modules or various SDK integration, navigation is sometimes tedious to work with but it is worth it really.
I don't regret at all the choice of migrating our app to RN one year and a half ago.
Appreciate all the work FB is doing here, but RN is fundamentally never going to be a solution for most teams. The compounding problems (JS/swift/obj-c/java) and their dependencies in the build process demand that you hire native developers. That eliminates the #1 reason to use it.
After 3 times using RN and having to go back to native... never again. When even simple things like navigation or animations take hours of research to get right.
My experience building a couple of (fairly simple) apps on React Native has been amazingly productive and very pleasant dev experience. I've built a couple of toy apps in Swift directly and can honestly say that I find RN faster and easier. (And I'm neither a mobile dev nor a Javascript expert.)
The hardest part for me was getting React-Navigation and RN-Web to play nicely together so I could have substantially one codebase for 3 platforms. That was admittedly a fair bit of googling and fiddling.
I used it ~1.5 years ago and would consider using it again even if it only worked on Android, just to avoid having to implement designers' various flights of fancy in native Android. Styling, at least back then (I really doubt it's improved—it'd already been bad for years) was horrible as soon as you deviated much from "change the colors". Bizarrely, their support for their own crap, like Material Design, wasn't even very good. Worse than it was in web-focused JS libs from the big G. Fits the pattern, I guess—their Android maps API was missing features from their web/JS one, too.
This despite the fact that React Native was in fact a giant pain in the ass for a bunch of reasons. Native Android styling's that bad. Also saved me having to run Android Studio most of the time, which is a bonus. Though to be fair AS is more pleasant than Eclipse was, at least.
When even simple things like navigation or animations take hours of research to get right.
When a developer suggests spending "hours of research" on a problem is enough to make them abandon a potential technology, I don't often think the problem lies with the technology.
For what it's worth my team uses React Native and we've faced the same problems; we solved it by making sure every project has one dev capable of doing the lower level native work. That still means the rest of the team can be web developers, who are much easier to hire because more people know that stack. That alone makes RN a good bet despite its quirks.
I'm a designer but I also do front-end development and for me RN is pure fun! Easy to implement screens, add animations… the development experience has been great so far.
Interesting, I thought I had seen it mentioned somewhere (Twitter, I believe?) that hooks would only be available on v0.60. Excited to see them integrated so fast!
I feel like the React Native fad has come and gone. Even FB is using their own server-driven UI solution nowadays, which allows clients to be dumber while still rendering native components.
When I worked on the main iOS app at Facebook they used multiple solutions in parallel in the app (ComponentKit, AsyncDisplayKit, RN).
So the fact that some projects are using some new server driven technology for some features doesn’t really prove anything.
Unless they specifically announce they are dropping RN support from the app or you see a big drop off in pull request activity I wouldn’t jump to any conclusions.
I apologize for not really commenting on the content of the release, but I am shocked that it is on version 0.59.
I wonder why they even bother with supposedly following semver at this point. 0.59? This seems to mean they can break anything at any point and it's technically still "following semver". I guess I just don't understand it. This library is used by thousands and consumed by millions (billions?). Why not just use dates as versions?
[+] [-] vjeux|7 years ago|reply
Fabric: https://github.com/react-native-community/discussions-and-pr...
TurboModules: https://github.com/react-native-community/discussions-and-pr...
Codegen: https://github.com/react-native-community/discussions-and-pr...
JSI: https://github.com/react-native-community/discussions-and-pr...
[+] [-] flaie|7 years ago|reply
Of course some stuff sometimes doesn't work well, react-native link versus Pods, native modules or various SDK integration, navigation is sometimes tedious to work with but it is worth it really.
I don't regret at all the choice of migrating our app to RN one year and a half ago.
[+] [-] matchbok|7 years ago|reply
After 3 times using RN and having to go back to native... never again. When even simple things like navigation or animations take hours of research to get right.
[+] [-] sokoloff|7 years ago|reply
The hardest part for me was getting React-Navigation and RN-Web to play nicely together so I could have substantially one codebase for 3 platforms. That was admittedly a fair bit of googling and fiddling.
[+] [-] asark|7 years ago|reply
This despite the fact that React Native was in fact a giant pain in the ass for a bunch of reasons. Native Android styling's that bad. Also saved me having to run Android Studio most of the time, which is a bonus. Though to be fair AS is more pleasant than Eclipse was, at least.
[+] [-] onion2k|7 years ago|reply
When a developer suggests spending "hours of research" on a problem is enough to make them abandon a potential technology, I don't often think the problem lies with the technology.
For what it's worth my team uses React Native and we've faced the same problems; we solved it by making sure every project has one dev capable of doing the lower level native work. That still means the rest of the team can be web developers, who are much easier to hire because more people know that stack. That alone makes RN a good bet despite its quirks.
[+] [-] BucketSort|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
Only use platform languages for production code, anything else just adds more FFI, debugging effort, lack of tooling and impedance mismatchs.
So for portable mobile apps, I am a big supportive of C++ with native views, or just plain mobile Web, specially now with PWAs.
For customers only focused in a specific platform, then full native.
[+] [-] edmundo|7 years ago|reply
[+] [-] raitucarp|7 years ago|reply
[+] [-] pvinis|7 years ago|reply
https://github.com/pvinis/rn-diff-purge
[+] [-] TheCoreh|7 years ago|reply
[+] [-] onion2k|7 years ago|reply
[+] [-] blkhp19|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] htormey|7 years ago|reply
So the fact that some projects are using some new server driven technology for some features doesn’t really prove anything.
Unless they specifically announce they are dropping RN support from the app or you see a big drop off in pull request activity I wouldn’t jump to any conclusions.
[+] [-] aaaaaaaaaaab|7 years ago|reply
[+] [-] pizza|7 years ago|reply
[+] [-] madebysquares|7 years ago|reply
[+] [-] skluck|7 years ago|reply
I wonder why they even bother with supposedly following semver at this point. 0.59? This seems to mean they can break anything at any point and it's technically still "following semver". I guess I just don't understand it. This library is used by thousands and consumed by millions (billions?). Why not just use dates as versions?
[+] [-] terragon|7 years ago|reply