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.
Airbnb suffers from a problem I call "Too many engineers". All that's really left is scaling issues.
The product is effectively done. It was done years ago. Now you just have engineers inventing problems for the sake of creating work. Same deal with Uber, Netflix, and Facebook. Core competency was dev complete forever ago.
- Writing a 5 part blog post on why they're moving away from that technology
Look I love Lottie, but it's hilarious to me how far outside of "Facilitating short term rentals" it is. Facebook has the same thread to pull with React. I get that they're "trying to contribute to the ecosystem" but it's like an extension of the PhD for these coders.
All of this is valid and I don't really disagree, but would add that a lot of these longer lived companies do seem to spend a lot of resources on projects that are nothing like the items you listed and do seem rather pointless.
I have not but my co-founder worked at Uber for 5+ years. He said they had engineers basically building whatever anyone wanted. He said they built their own Slack more or less just because they could.
It's sad, because if they would just travel the world (or look at the data) instead of building unnecesary infrastructure, they would realize how broken the Uber experience is in less developed countries.
Data quality issues, like missing tolls, intersection being different on Uber's map than in real life means that Uber is underpricing drivers, which leads to driver cancellations. It was very frustrating for me to start the whole process again mutiple times after waiting 5-10 minutes and try to haggle with the drivers all the time.
I think it's likely that they don't put much value in delivering a quality product in these markets, where the revenue is relative peanuts compared to first world countries. It's enough just to exist there and claim the territory for the brand. And they can always just blame the sub-par experience in these areas on bad infrastructure. Retaining talent by keeping their engineers happy with pet projects is probably much more important to the company.
They did need them at one point. And the product was successful enough that nobody in management ever had to get around to cost cutting, in the cases of Netflix, Facebook, etc. But that doesn't mean engineers are doing anything important.
I asked a similar question to a sibling comment in this tree but have you considered that there's a lot more than meets the eye at these companies? If the product seems "simple", "done" or "just works" that's a good thing and intentional.
A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?"
"It will take one year," said the Master promptly.
"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"
The Master Programmer frowned. "In that case, it will take two years."
"And what if I assign a hundred programmers to it?"
The Master Programmer shrugged. "Then the design will never be completed," he said.
I'm interested in why you feel that way about Netflix. I've been digging into their source code and it's a complicated beast, with flags such as `isGreekAndSafari`. Beyond that, they have to deal with all the random business rules that each country has around content. It's given me a big appreciation for what they do, which others might boil down to something that's simpler than it actually is ("it's just streaming video, come on").
Reminds me of how people treat web developers in comparison to "real developers". I think perhaps it's just human nature to downplay the work or job of others.
I don't disagree that some places might have too many engineers, but I also think you underestimate the complexities of running a product that operates in every corner of the globe. And wants to provide a damn good experience in every corner of the globe.
So it's insane to me that you think their problems are "done" or "solved". That's how you end up falling behind and becoming an outdated business. These companies are trying to be proactive, not reactive!
Those problems you describe are about implementing business rules - that’s not particularly interesting work provided the system has been well-designed. I imagine the glamorous work at Netflix for building out their scalable infrastructure for delivering terabytes of content every second largely ended years ago - of course that work is ongoing as new delivery systems and transports emerge and content consumption habits evolve (remember when people used to think you could only watch Netflix Streaming on a computer?) - but that needs far fewer people to accomplish, and it would be evolutionary work, not revolutionary.
> I think perhaps it's just human nature to downplay the work or job of others.
Of course it is! But as far as Netflix, and all other employers are concerned, they need to offer jobs that are either “interesting” or glamarous - otherwise there’s nothing to attract the best talent when they’re already paying top-tier Bay Area comps just to compete with Google and Facebook. (Why they don’t try to compete with PTO is beyond me - I told one recruiter I’d work for 20% less comp if they doubled their miserly 15 days PTO and they never got back to me - but that’s another story).
Now in my case, the work I do for my day-job isn’t glamorous at all: it’s just a straightforward line-of-business SaaS application. I’m not looking to change my employer at all (for reasons I won’t go into - but I do get 45 days PTO), but if I was looking I wouldn’t accept a job at a big name if it’s just to do /routine/ work. I want to be able to blog about my work and have people at least say “oh hey, that’s cool”.
I agree that companies tend to over hire. My company certainly does, which leads to things taking much more time they would with less folks (and often more buggy). It's the age old problem of throwing engineers at things thinking it'll speed things up I guess.
I disagree that there isn't exciting work to be done at these places. I think you're just as likely to be bored at any other job, you just get paid boatloads more. Most end up running off to do their own thing since they have the financial freedom to do so after a few years.
For what it's worth, I think you'd be able to blog about your work at Netflix, Google, Facebook, etc. Plenty of their employees do so.
EDIT (you added in some PTO details): Heck I wouldn't leave if I got 45 days PTO either! Yeah, I hope companies start competing more on hrs of work. I'd gladly take a hefty pay cut to work 20 hrs a week.
> I think you'd be able to blog about your work at Netflix, Google, Facebook, etc. Plenty of their employees do so.
There’s two types of work-blog: the kind you have on your personal website - and the kind on the company’s own blog.
Most companies prohibit what you can talk about on your own blog (rightfully so - competitive secrets, etc) but some companies like a Apple outright prohibit you talking about your work to others at all beyond generalities.
Company-run blogs, for all their casual demeanour, are still ruled by management - and one’s blog articles become their copyright unless otherwise stipulated (as it’s a work stemming from your employment). When/if the company ceases to exist - so do your articles.
I had my own blog on blogs.msdn.com when I was at Microsoft - I sometimes posted somewhat subversive articles (such as guides on how to tweak the appearance of components of Windows if you didn’t like the defaults using publicly available articles and documentation) - I was hoping it would still be online today but it seems most MSDN blogs that didn’t reach Raymond Chen-levels of popularity got axed when the “MSDN” brand was retired. Oh well...
I think having flags like isGreekAndSafari could also possibly be a sign of too many engineers. I never really understand why large scope and/or scale business rules require more engineers. Why do companies program all this stuff directly into the app with crazy flags like that instead of building configuration systems so that lower cost employees can fill in and expand the business rules?
What kind of language and configuration system do you suppose would be viable for doing this? What kind of system would let "lower cost employees" fill in and expand the business rules?
Reminds me Stripe, the payment processor, who wrote a custom internal social media network: https://stripe.com/blog/stripe-home It seems many tech companies have trouble de-engineering themselves and get stuck in a loop of endlessly rewriting/migrating/redesigning because they have a massive technical staff all trying to prove their value. Google definitely suffers from this. No glory in fixing the existing chat app, so just write a new one with new problems, justifying the creation of a newer one etc. Microsoft has it even worse because they can't delete any of the old interfaces for compatability reasons, so they just pile on layers of parallel systems.
Looks like that was the product of an internal hackathon. That said, your point is still valid; companies often experience these little internal pivots. In large companies, it becomes make-work empowering a Not Invented Here culture. In smaller companies, too much obsession over tangential projects lead to misprioritized boondoggles that might potentially threaten their futures.
I'd agree on AirBnB and Netflix but not Facebook and Uber. Facebook has continuous challenges with content/abuse/moderation and Uber has continuous challenges with routing/optimization/pricing of their pooled rides.
Have you considered the possibility that the first two companies you've mentioned have just fooled you into thinking their product is complete by offering you a complete feeling experience? There's a difference between "this feels whole" and "there's nothing more to be done here". I would say those two companies have iceberg effects with their products -- the customer interacts with a very focused piece of it.
Totally agree. I have wondered what exactly engineers at... Netflix, for example, do on a day to day basis. The product plays videos, right? Its played videos for...years. Their newer features are pretty clear overengineering efforts like "Smart downloads". Because they've run out of shit to do so badly that the app will literally just start downloading things on your behalf without you. Why is this at all necessary? What users asked for this? Its exactly the kind of thing someone who had nothing else to do would come up with.
Maintaining infinite platform/device compatibility, optimising video delivery, reducing bandwidth costs and new features to push the medium forward (like the choose-your-own-adventure thing they made).
Video delivery is hard. If you spend a month working on a basic Netflix clone showing a single clip it won't be 1/100th the performance of Netflix even if you use a CDN.
Netflix has optimizations for individual ISPs by placing content servers directly in their DCs.
Also, large organizations accumulate constant tech debt that need to be paid down. Features aren't infinitely scalable.
The fact that they have people optimizing that obsessively is an indication of how little real work there is to be done. The thing plays videos, its played videos for years upon years, and all that's left in engineering terms seems to be to make it faster to a small degree that no user is likely to even detect.
It's not just playing video. Actually playing the video is easy. Delivering it to the end user is enormously challenging.
Even with a top-shelf CDN, you will have a non-negligible amount of customers having playback issues because of routing issues, peering disputes, congestion etc.
If delivery was easy, Akamai would not be a multi-billion dollar company. Microsoft wouldn't pay them millions, they'd just spin up some content servers themselves.
Saving X kb per 30 minutes of video streamed is "obsessively" optimizing something if you're serving a single video. If you're over 10% of all of Internet traffic, that can be millions of dollars saved a year, which pays for more than a few engineers even at SV salaries.
As a user I certainly appreciate it, but I think the actual content being delivered plays a much larger role than how many milliseconds its delivered in.
Compare it to Disney+ or HBO Go and you’ll learn why the comparison isn’t that simple. Netflix starts faster and doesn’t pause under a much broader set of network conditions because there’s a team of people improving it. Those other products support fewer devices and it still shows how much room there is to mature beyond the basic level of service you get with redundant servers and a CDN.
I worked at Airbnb during this time, and basically it came down to the fact that it just didn't make sense to invest in RN.
The company already had 50-100 native engineers already productive and passionate about iOS/Android with internal tooling, large code base and support from Google and Apple (like you could contact Apple when there was a performance problem on Swift and they would sometimes come over to diagnose). Most native engineers didn't want to do React Native and most web developers didn't want to deal with native mobile both on iOS and Android. There was always some edge cases, navigation quirks or performance problems, where in order to fix it, you had to know the platform somewhat well. Most engineers are not that familiar with both iOS, Android and RN. So who would want to do it? Also just to support RN as a platform, you needed 1-2 engineers full-time just keeping it working and resolving issues with the platform (which is not that different from iOS/Android).
To get it fully adopted, you would have to basically restructure the mobile teams, recruit new people, rewrite the code base and tooling to make the switch. RN was experiment to see if teams would be more productive and make sense for the company but it didn't since the company had already invested so much native.
There is also something to be said about building a new app in RN vs trying to build an performant app that has over 10 years of functionality, runs both Guest and Host experience in the same app, is internationalized to 30 languages/locations (each city in the world has their own regulation which affect taxes, what data needs to be collected etc), is run on wide range of devices and runs hundreds A/B tests and gradual feature rollouts. It's classic "I could build X in a weekend" if you only focus on the very common surface level features.
With many frameworks or languages people often love the experience of building a new app. After maintaining the app over years with several developers, platform upgrades etc the feeling might change. I wonder what are largest, most widely used and longest running RN apps out there?
I've long been curious whether Airbnb was too early adopting or it simply made more sense for such a big company to go native (also factoring in Swift/Kotlin making native mobile dev less-bad in the meantime), from the article:
> Many of these features were built at a time where we simply did not have enough native engineers to achieve our goals.
> we’ve grown our team to more than 100 mobile engineers to enable new experiences and improve existing ones.
Or maybe React Native truly added more baggage than it's worth going cross-platform.
Cross-platform has always been sort of a pipe dream that has haunted programmers since forever, but especially since mobile browsers and non-shitty JS became a thing (Linux and MacOS/OSX are still having their perpetual moment as well).
I plan to revisit the Airbnb series regardless since I forgot most of their reasoning...
Or maybe they hired a bunch of engineers to move fast and break things, promoted them, and now those same people are leading their engineering efforts and trying really, really hard to do something they suck at, which is writing maintainable code.
React Native 2020 is far superior to RN of 2017/18.
I built an app in RN in 2017 and it was a real headache actually getting anything to build. I've since built another one, far more complex than the previous one in the last few months and it's been a real surprise as how stable and dare I say, easy, it actually is.
Saying all that, I haven't attempted to upgrade from RN 0.61 to 0.62 and expect issues from this.
I've always worked in relatively large companies, and I've led several mobile teams. I've always ALWAYS been a native mobile purist. I had iOS people writing Obj-C and Swift, I had Android people writing Kotlin/Java. I had budget to have at least 2 of each and things moved along.
Now I find myself a CTO of a startup where mobile is less crucial (we're building an issue tracker to take on Jira/Trello/etc) and I don't have a big budget anymore. I need to seriously consider something like RN or Flutter.
Anyone else been in this situation where picking a cross-platform toolkit is not a matter of trend or religion but rather one of necessity? Any learnings to share?
Is there even any evidence that RN or Flutter are better for smaller budgets? Like actual data that doesn't live in the mind of a RN/Flutter enthusiast?
That’s a very good question. The reality may be that if one cannot afford at least one native iOS dev and one native android dev (given the size of the app that person could share other duties) then one is not in a place to launch a mobile app
Weird that the site is still as slow as it's always been, how have they not fixed this, it's slow on desktop it's slow on the app it's always the slowest thing. Slower than local news websites. S l o w.
I gave up using them when they switched from showing places to stay to showing (by default) all kinds of crap that I didn't care about.
I was a business user, with a business account and business credit card. Why am I being shown "experiences" as the default behavior?
In the end I was forced to quit due to my account being in some weird state that they STILL haven't fixed (I checked today, a year and a half later). All that happens when I log in is I see "We’re reviewing your info
Someone from our team will review your account and follow up with you soon at <email>"
This is after many years of bookings and absolutely zero disputes or complaints etc. Emailing them gets me nowhere - just no response at all.
Every time there’s a thread about React Native the RN fanboys come in droves, the reality is that RN is an abstraction over Native Mobile and will always be inferior to it.
You will end up debugging issues for supporting multiple platforms via one codebase.
I like React just not for Native Mobile, nowadays stick to native Swift or Kotlin and wait for SwiftUI and Jetpack Compose to make Mobile development seamless
I'd love to use a better language like Swift or Kotlin for cross platform development but in reality, between Typescript which is a ubiquitous language with a lot of traction and potential and Dart, a me too language with limited usecases that Google tries so hard to shove down our throat, I know what I prefer.
Dart lost to Typescript before in the javascript war, btw
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.