React Native 0.59.0-rc.0 released(github.com)
github.com
React Native 0.59.0-rc.0 released
https://github.com/facebook/react-native/releases/tag/v0.59.0-rc.0
40 comments
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.
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.
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.
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.
My experience (as a senior native Android dev) has been definitely bad so far. Configuration errors and inexplicable error messages popping up on a regular basis.
The amount of troubleshooting it constantly required - instead of focusing on the task at hand - started to feel cumbersome after a week or two. Simplest functionality such as breakpoints would randomly stop working. All these problems aren't exclusive to me, I would pretty much always succeed in googling them up, usually along with dozens of solutions suggested by the community (each of them different).
The documentation and tutorials leave a lot to be desired, too. A lot of this stuff is outdated, and the official documents are imprecise and feel like a draft (even when compared to what the much less mature Flutter brings to the table in this regard).
Tooling is far behind what you get if you go native. Eg. support for refactoring, whatever editor you use, will be more than rudimentary and virtually nonexistent in comparison to what Android Studio offers. The same goes for unit testing / integration testing support, it's rather iffy.
One of the more important UI Android features - Material transitions - is pretty much impossible to recreate in React Native.
I also don't find JavaScript - even with TypeScript on - nearly as good a language as Kotlin.
This isn't meant to be a rant: just an honest summary of my few weeks of experience fiddling with RN. You mention your native development was done in Swift; I heard that React Native is allegedly much more reliable for iOS than Android development. I can't really verify it either way, but potentially this might be why our mileages vary.
The upsides? React Native pretty much abstracts away the lifecycle concerns, which are still a pain in the neck for a native Android dev. Hot reloading. No obsolete APIs maintained for backwards compatibility; understandably. Asynchronous programming is simple enough (although with Kotlin's coroutines arguably on their way to become the go-to solution on Android, it's not necessarily a win over native). Nothing else has impressed very much me so far. I used Xamarin for a commercial project once, and it felt considerably better, even though it was three years ago.
The documentation and tutorials leave a lot to be desired, too. A lot of this stuff is outdated, and the official documents are imprecise and feel like a draft (even when compared to what the much less mature Flutter brings to the table in this regard).
Tooling is far behind what you get if you go native. Eg. support for refactoring, whatever editor you use, will be more than rudimentary and virtually nonexistent in comparison to what Android Studio offers. The same goes for unit testing / integration testing support, it's rather iffy.
One of the more important UI Android features - Material transitions - is pretty much impossible to recreate in React Native.
I also don't find JavaScript - even with TypeScript on - nearly as good a language as Kotlin.
This isn't meant to be a rant: just an honest summary of my few weeks of experience fiddling with RN. You mention your native development was done in Swift; I heard that React Native is allegedly much more reliable for iOS than Android development. I can't really verify it either way, but potentially this might be why our mileages vary.
The upsides? React Native pretty much abstracts away the lifecycle concerns, which are still a pain in the neck for a native Android dev. Hot reloading. No obsolete APIs maintained for backwards compatibility; understandably. Asynchronous programming is simple enough (although with Kotlin's coroutines arguably on their way to become the go-to solution on Android, it's not necessarily a win over native). Nothing else has impressed very much me so far. I used Xamarin for a commercial project once, and it felt considerably better, even though it was three years ago.
Very likely. We basically “don’t care” what our apps precisely look like, so long as they function and the user is not impeded in getting access to their data. (They’re simple line of business data access/overview apps.)
If we cared about platform perfect compliance with standard UX, it might be more challenging. Of course, if cared about native perfection, we probably wouldn’t be trying an inherently cross-platform tool.
If we cared about platform perfect compliance with standard UX, it might be more challenging. Of course, if cared about native perfection, we probably wouldn’t be trying an inherently cross-platform tool.
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.
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.
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.
Basic navigation from screen to screen shouldn't require any research. It doesn't for native platforms. Facebook doesn't provide a built-in solution, which speaks volumes.
Core navigation still doesn't "just work" for RN. At all. The pure JS solutions are garbage and limit what you can do tremendously. The native solutions have tons of other issues you have to hack around.
Core navigation still doesn't "just work" for RN. At all. The pure JS solutions are garbage and limit what you can do tremendously. The native solutions have tons of other issues you have to hack around.
What's wrong with using react-router? That's just one solution that I've found easy and without significant limitation. Easier than native solutions. I'm predominantly a web developer who uses React and related technologies a lot, which makes me wonder if many of the people who are frustrated with RN aren't exactly the target audience and will hit a learning curve.
React Native isn't even 1.0 yet. They are working on lessening the need for native development.
Being on the loosing side with a couple of loved languages, I learned something that I always promote in any project I am part of.
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.
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.
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.
Because dx (developer experience) is also important, I suggest you to considering use Expo
I'll just plug my repo here that helps with upgrading existing RN projects to new versions.
https://github.com/pvinis/rn-diff-purge
https://github.com/pvinis/rn-diff-purge
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!
Nope. Hooks are in 0.59. https://twitter.com/reactnative/status/1093889810006200326?s...
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.
[deleted]
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.
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.
It’s gone and for the better. The tipping point was the Airbnb blogpost.
If you actually read the full blog you'll realize it'll actually convince the right people to either adopt or avoid RN:
>The path of a world that is 100% native or 100% React Native is relatively straightforward.
but ultimately... hybrid apps are hard. Airbnb had a ton of infrastructure that needed porting over to RN that often required contributing upstream to fix issues they found. If you're starting from scratch you can get pretty far sticking to React/JS.
imo I can't imagine a startup using anything other than RN (or react-native-web) because of how quickly you can build things.
>The path of a world that is 100% native or 100% React Native is relatively straightforward.
but ultimately... hybrid apps are hard. Airbnb had a ton of infrastructure that needed porting over to RN that often required contributing upstream to fix issues they found. If you're starting from scratch you can get pretty far sticking to React/JS.
imo I can't imagine a startup using anything other than RN (or react-native-web) because of how quickly you can build things.
I built my startup using Ionic/Cordova (since certain APIs weren't available on RN). Now that iOS 12.2 beta is out, it is breaking certain APIs and leaving me no choice but to abandon the hybrid model. If anyone else out there is planning on doing anything other than a simple photo sharing/PWA app, don't bother with hybrid - you'll have to go Native at some point.
Can you expand on the APIs that broke for you?
That's is just not true.
What would you say comes after RN?
The realization that avoiding native brings more problems than it solves and that for CRUD apps mobile Web is good enough.
Flutter?
That sounds interesting, source?
Engineering manager of React denied this claim, previous discussion: https://news.ycombinator.com/item?id=17216628
Note that the claim that was denied was Facebook moving away from React Native.
Server-driven UI rendering and Litho/ComponentKit are also growing along with React Native. Facebook app has a big enough surface that it makes sense to have different rendering strategies for different use cases.
Server-driven UI rendering and Litho/ComponentKit are also growing along with React Native. Facebook app has a big enough surface that it makes sense to have different rendering strategies for different use cases.
Server-driven UI rendering and React-Native isn't mutual exclusive though.
Server can still render a React-Component-tree-like structure that will then be used in the client to render the actual component in react native. This gives you ability to make some UI layout/theme adjustment from the server, which is good for A/B test. Doesn't means it goes back to rendering every view from the server on every interaction.
"Facebook app has a big enough surface that it makes sense to have different rendering strategies for different use cases."
That's an odd statement. Playing mix-n-match with rendering strategies without a very clear UX justification for doing it is an invitation for designers and mediocre product people to indulge themselves at the expense of the overall UX.
That's an odd statement. Playing mix-n-match with rendering strategies without a very clear UX justification for doing it is an invitation for designers and mediocre product people to indulge themselves at the expense of the overall UX.
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?
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?
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...