I’m an engineering manager, and made the call to build a new mobile application for our company in React Native in early 2019. I read this article back then and considered various options before picking RN.
I have built apps in native iOS (pre-swift), Android (Java), windows phone (c#), phonegap/Cordova/ionic capacitor (cross platform web w/ native plugins), and Xamarin.
I did a POC of the app in RN before my team started building it, and I fell in love with it. We moved to the beta with Fast Refresh and the experience of building the app was great. Expo is huge too if you don’t need custom native like we did (we’re building an order processing app for a custom Android scanner).
Overall I feel that React is the best tech for building frontends that we have so far, and TypeScript makes JS quite nice.
Downsides to RN were the entire package dependency tree getting messed up every time we upgraded (could have been our newness to the platform at play), and the first version of the app that was not built with react best practices was really slow and had a lot of bugs. We had to go through a rearchitecture once we learned how to properly use immutable state, redux, selectors, slices, etc. we use redux toolkit and redux saga, and it has full offline support with automatic resyncing when it reconnects. It is a very slick, high performance app now. I’m not sure we saved any time doing RN because of the learning curve, but now that the team is spooled on this architecture, it’s paying huge dividends as we build electron desktop apps and websites with React as well.
Your use case is the situation where React Native thrives. You get code sharing across platforms and a leg up with election and stuff like that.
I view Airbnb's failure with it more of a (justified) lack of will.
They already had native apps rolled out and were tacking things on with React Native.
I feel it's best to invest in the largess of the codebase being in React Native and digging into native apis when needed
"A common misconception is that when Airbnb decided to use React Native, that they made a complete switch. This is not only not true, but to this day the React Native code represents only 15-20% of the codebase and developer resources. It was never a majority platform for the company, and part of that was the immense upfront cost to enable even the first set of components for the mobile platforms.
Even though React Native is a framework and vastly simplifies mobile development, it is not trivial to get up and running, particularly if you have an existing codebase. Expect to invest a substantial amount of time and energy to integrating React Native into your existing mobile codebase"
Airbnb decided it wasn't a priority to finish the job.
That's a fine choice I just don't see it as wholesale indictment of React Native as it was originally sold in that article.
This topic seems to bring out the worst in programmer religious wars.
Small company, limited resources, greenfield app that needs to be on all platforms: React Native is a no-brainer that'll help you survive and thrive.
Large company, large existing native codebase, no shortage of resources: RN will be an expensive, divisive distraction that doesn't gain you anything. It can make a lot of sense for prototype projects, but that use case is pretty similar to the former.
I'm a big fan of RTK, especially the immutable state out of the box. The biggest issue I had with onboarding was that the docs are geared toward users who already use and are familiar with Redux, React, and React-Redux (the first line in the tutorial even says to go read those docs first).
I completely understand the stance to not want to replicate documentation, but I also feel that RTK's opinionated approach, and tooling that is built in, satisfy most use cases of React-Redux apps. So I do wish that RTK was given more weight than plain React-Redux and had a smoother onboarding experience.
As an example, Create React App is a similar "batteries-included", and the docs for React have a direct tutorial on how to get started with CRA in their docs, while the Redux documents just mention Redux Toolkit at a high level in the Getting Started with Redux and then link you to the tutorials, which then tell you to go back and read the Redux docs to understand the concepts.
The problem we ran into is that we read about RTK early on in learning Redux, but didn't understand the concepts enough to know how much easier RTK was to use and maintain, so we built the whole app on plain Redux, then ended up having to convert it and strip out a bunch of manual code later. I think a focus on the onboarding to RTK should be emphasized.
I really can't imagine a situation where anyone would be better off not using RTK unless they were after a very small bundle size, but it's pitched a sort of an "optional" kind of thing. I'd rather you be opinionated and tell me I should really use RTK and not write stuff myself, then link me to a guide that doesn't assume I know anything about Redux and doesn't start with converting an existing Redux app, but just teaches the Redux concepts in a "clean-room" where you don't assume I know anything about Redux.
Again, I LOVE RTK and all the work you all put into it is greatly appreciated. But a slightly better educational flow on the reason I would want RTK could have saved us a month or two of dev time rebuilding everything on top of RTK at the tail end when we got familiar with Redux and realized all the issues we were creating by not using immutable updates, slices, thunks, consistent actions w/ automatic action creators, memoized selectors, integration with TypeScript, etc.
The good news is that I have been working on a new "Quick Start" tutorial for the Redux core docs [0], which is _exactly_ what you're describing there: an intro to Redux, for folks who have never used it before, which teaches RTK and the React-Redux hooks APIs as the default way to write Redux logic.
We also have an open issue to discuss reworking the RTK tutorial sequence [1], as there's agreement that the current RTK tutorials focus too much on migration, and the "Advanced" tutorial shouldn't include TS usage.
As I said in that issue thread, it's very hard to know how to split the onboarding flow and explanations between the Redux core docs and the RTK docs. RTK _does_ work best when you actually understand how plain Redux works and how to write Redux code "by hand", and can see the benefits and purpose of abstractions like `createSlice`. So, yeah, ideally everyone would go through the bottom-up Redux tutorial sequence at some point so they fully appreciate what RTK is doing for them.
On the other hand, it's true that RTK is a lot simpler to use, code-wise, and that there's less syntax to confuse people if they're getting started. Problem is, you still need to know concepts like "dispatching actions", "reducers", and "immutability", even if you're jumping straight into RTK.
So, bottom line: this new "Quick Start" tutorial covers exactly that "start Redux with RTK as the default" use case you're describing, and after that's done, my next task will be to rewrite the existing Redux core tutorial sequence. It'll still be a "bottom-up / how it all works by hand" approach, but updated to remove outdated content (like references to "Flux") and show simpler patterns (inline action type strings, "todos/todoAdded" instead of "ADD_TODO", single-file Redux "ducks" logic, etc).
I still don't have a good answer for how to handle the RTK tutorials, but I'm going to paste your feedback into that linked thread, and would appreciate any other suggestions you have in that regard.
I was following along until you claimed the app was "high performance". Speaking as a mobile engineer and a React developer, I struggle to see how a laundry list of abstractions over native code could be more performant than the average, native code.
Yes, this. It's a business app for a scanner. It's the only app running on a device with an 8 core processor and 4 gigs of RAM.
It starts up in a couple seconds, all interactions feel instant, it syncs smoothly. Photos are quick to take, scans of barcodes happen right away. The UI re-renders whenever things change either on the server or the client app.
There is nothing about the UX that feels non-native whatsoever.
I have built apps in native iOS (pre-swift), Android (Java), windows phone (c#), phonegap/Cordova/ionic capacitor (cross platform web w/ native plugins), and Xamarin.
I did a POC of the app in RN before my team started building it, and I fell in love with it. We moved to the beta with Fast Refresh and the experience of building the app was great. Expo is huge too if you don’t need custom native like we did (we’re building an order processing app for a custom Android scanner).
Overall I feel that React is the best tech for building frontends that we have so far, and TypeScript makes JS quite nice.
Downsides to RN were the entire package dependency tree getting messed up every time we upgraded (could have been our newness to the platform at play), and the first version of the app that was not built with react best practices was really slow and had a lot of bugs. We had to go through a rearchitecture once we learned how to properly use immutable state, redux, selectors, slices, etc. we use redux toolkit and redux saga, and it has full offline support with automatic resyncing when it reconnects. It is a very slick, high performance app now. I’m not sure we saved any time doing RN because of the learning curve, but now that the team is spooled on this architecture, it’s paying huge dividends as we build electron desktop apps and websites with React as well.